 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thies Heidecke wrote:
>
> Additionally, i have two questions:
> POV-Ray creates a 'memory.log'-file when i render an image, which grows
> quite rapidly and contains many lines like:
> [...]
It would be quite helpful if you'd say which version you are using. The
Linux version does not generate a memory log file.
> And, the documentation (2.7.2.2.2.) says:
> 'A number of sample direction sets is coming with MegaPOV as include files.'
> I'm just curious if they aren't ready yet in the beta or if they were
> forgotten?
I did not have the time to put them together.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmx de> schrieb im Newsbeitrag
news:cfvhgi$5v1$1@chho.imagico.de...
> Thies Heidecke wrote:
> >
> > Additionally, i have two questions:
> > POV-Ray creates a 'memory.log'-file when i render an image, which grows
> > quite rapidly and contains many lines like:
> > [...]
>
> It would be quite helpful if you'd say which version you are using. The
> Linux version does not generate a memory log file.
>
I'm using:
megapov-1.1-beta_windows.zip (5271kB)
Windows GUI version compiled with MinGW.
>
> > And, the documentation (2.7.2.2.2.) says:
> > 'A number of sample direction sets is coming with MegaPOV as include
files.'
> > I'm just curious if they aren't ready yet in the beta or if they were
> > forgotten?
>
> I did not have the time to put them together.
>
Ah, ok, thanks for the info.
> Christoph
Thies
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 18 Aug 2004 14:06:44 +0200, "Thies Heidecke" <h3i### [at] gmxnet> wrote:
> Additionally, i have two questions:
> POV-Ray creates a 'memory.log'-file when i render an image, which grows
> quite rapidly and contains many lines like:
> File:source/blob.cpp Line:2212 Size:4
> File:source/blob.cpp Line:3445 Size:64
> File:source/blob.cpp Line:2212 Size:4
> File:source/blob.cpp Line:2273 Size:4
> Are these memory-leaks, or just some kind of 'routine' logging?
Hard to say without complete scene. It did not occured here, so please send
directly to me a scene file you are using. I will look whether this is a
MegaPOV or regular POV-Ray problem. Thanks for reporting it.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ABX" <abx### [at] abxartpl> schrieb im Newsbeitrag
news:k3j6i0hpphphgh6imiear2bp85io97spem@4ax.com...
> On Wed, 18 Aug 2004 14:06:44 +0200, "Thies Heidecke" <h3i### [at] gmxnet>
wrote:
> > Additionally, i have two questions:
> > POV-Ray creates a 'memory.log'-file when i render an image, which grows
> > quite rapidly and contains many lines like:
> > File:source/blob.cpp Line:2212 Size:4
> > File:source/blob.cpp Line:3445 Size:64
> > File:source/blob.cpp Line:2212 Size:4
> > File:source/blob.cpp Line:2273 Size:4
> > Are these memory-leaks, or just some kind of 'routine' logging?
>
> Hard to say without complete scene. It did not occured here, so please
send
> directly to me a scene file you are using. I will look whether this is a
> MegaPOV or regular POV-Ray problem. Thanks for reporting it.
I've sent you an email with the scene attached.
> ABX
Thies
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well - that one is difficult. When i had a look at it i found it quite
> badly designed (or at least unusual). The syntax was not easy to use
> and misleading - specifying functions instead of floats without a
> wrapping function{} is not a good idea (*). Also i think Mael
> considered it incomplete - he wanted to add support for anisotropic
> finishes IIRC.
Actually I've never considered any of my patches complete or well
integrated. I've just done them for fun, to have a look at povray source
code and because some french povray users thought they could help. I have to
agree that my finish stuff is probably the ugliest hack of all, but still
think this is something important missing in povray
I did some tests with anisotropic finish (independant of finish maps AFAIR),
but it was requiring important changes and I was not willing to spend too
much time on this
Anyway I've stopped (bad) hacking on pov and returned on rendering
reflective spheres on checkered floors :)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 18 Aug 2004 15:41:56 +0200, "Mael" <mae### [at] hotmailcom> wrote:
> I've just done them for fun
Welcome to the club then ;->
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> It has taken a long time but we now have the new version ready, we
> intend to make a short beta phase (about a week, this of course depends
> if there are problems). Those who want to test can find the new version at:
>
> http://megapov.inetart.net/
>
Great to see this! So many new toys ... :-)
Firstly, many thanks for the new radiosity options. I'll look forward to
seeing the source, to see if you implemented the random rotations the same
way I did.
Secondly, a question. Have you considered using the 'new' 5th-order s-curve
for the noise function? It does tend to give a better behaviour for
perturbed reflections and such like.
Finally, an observation. In the WinMegaPov 1.1 the image viewed in the GUI
preview is the one before exposure/exposure_gain, where in v1.0 it was
after. A small thing, I know, but I can't see this change documented
anywhere?
Anyway, well done to all involved to get the new version out.
Mike.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>
> It has taken a long time but we now have the new version ready, we
> intend to make a short beta phase (about a week, this of course depends
> if there are problems). Those who want to test can find the new version
> at:
>
> http://megapov.inetart.net/
>
> You will see we also updated the website with a new sample scene gallery
> and some other useful information.
Thanks Christoph, and to the MegaPOV Team! The CodeWarrior version seems
to work fine on my machine (P4 1.6mhz, 512mb ram, Windows 98). It runs
slightly slower than the (unpatched) official POV-Ray release, but much
faster than the recommended download.
I'm glad to see mlPOV made it in.... all those other features are cool
as well (an HDR render I did actually got my older brother to gasp when
he saw it... rare). All those features are sure to keep me busy.
> We encourage those who have some experience with POV-Ray to test the
> beta version - this will help us to find possible flaws which might be
> there since it was quite some time since the last release. Please
> report problems to povray.unofficial.patches.
There does seem to be a bug in the camera_view pigment. When the
camera_view pigment is placed inside a pigment_pattern block, the (now
grey) shades of color stop at white and start at black again. In other
words, if you had a white sphere with light shining in it, the highlight
(diffuse finish) would appear to have black rings turning from
black-to-white instead of one smooth gradation. I'm sure this has to do
with the fact that the patch can't handle high color values yet. No
amount of color_mapping helped in this situation. I can make a file
demonstrating this, if needed.
-Sam
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Samuel Benge wrote:
>
> Thanks Christoph, and to the MegaPOV Team! The CodeWarrior version seems
> to work fine on my machine (P4 1.6mhz, 512mb ram, Windows 98). It runs
> slightly slower than the (unpatched) official POV-Ray release, but much
> faster than the recommended download.
That sounds promising, do you have some actual numbers for comparison
(preferably the benchmark of course).
> I'm glad to see mlPOV made it in.... all those other features are cool
> as well (an HDR render I did actually got my older brother to gasp when
> he saw it... rare). All those features are sure to keep me busy.
>
> > We encourage those who have some experience with POV-Ray to test the
> > beta version - this will help us to find possible flaws which might be
> > there since it was quite some time since the last release. Please
> > report problems to povray.unofficial.patches.
>
> There does seem to be a bug in the camera_view pigment. When the
> camera_view pigment is placed inside a pigment_pattern block, the (now
> grey) shades of color stop at white and start at black again. In other
> words, if you had a white sphere with light shining in it, the highlight
> (diffuse finish) would appear to have black rings turning from
> black-to-white instead of one smooth gradation. I'm sure this has to do
> with the fact that the patch can't handle high color values yet. No
> amount of color_mapping helped in this situation. I can make a file
> demonstrating this, if needed.
Sounds like a color clipping problem to me. It seems pigment_pattern
does not clip the values (this is the case in official POV-Ray as well).
Try:
pigment {
pigment_pattern {
bozo
color_map {
[0.5 color rgb 0.0 ]
[0.7 color rgb 10.0 ]
}
}
color_map {
[0.0 color rgb 0.0 ]
[1.0 color rgb 1.0 ]
}
}
As a workaround you could do the clipping yourself by using a function
pigment with a pigment function. :-)
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> LightBeam wrote:
>
>>
>> It's an excellent news ! I found megapov very impressive but... Where
>> is the
>> finish_map patch that was included in mlpov 0.83 ? I don't think that
>> patch
>> was:
>>
>> - buggy
>> - incomplete
>> - published too late to be included
>> - incompatible to POV-Ray 3.6 (I don't really know)
>> - no one found the time to add it (Really ;-) or in beta 2 ??)
>> - did not appear useful (I don't think so...)
>
>
> Well - that one is difficult. When i had a look at it i found it quite
> badly designed (or at least unusual). The syntax was not easy to use
> and misleading - specifying functions instead of floats without a
> wrapping function{} is not a good idea (*). Also i think Mael
> considered it incomplete - he wanted to add support for anisotropic
> finishes IIRC.
>
> In fact 'finish map' is a misleading name - a finish map would be
> something like:
>
> texture {
> pigment { ... }
> finish {
> bozo
> finish_map {
> [0 Fin_1][1 Fin_2]
> }
> }
> }
>
> (*) if it is nor clear what i mean imagine the following variation of
> the sample in the MlPOV manual:
>
> #declare fct = function { pigment { checker color rgb 0 color rgb 1
> scale .1 } }
>
> sphere { ...
> finish {
> uv_mapping
> reflection { fct (1) }
> }
>
> Should that be an incorrect call to function fct() or a function based
> reflection minimum and a constant reflection maximum?
>
> Christoph
>
I certainly understand the drawbacks with the implimentation. Just want
to add that I think it renders real world situations where the
depressions in a texture have a different finish that the protrusions.
So I find the functionality useful. There are workarounds I know but it
adds power and flexibility I thought.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
