 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Anyone with experience on setting up MC-Pov on a Linux machine? Especially how
to change the binary (and subdirectories) name to "mcpov" and identify itself
as such in the copyright notice?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> Anyone with experience on setting up MC-Pov on a Linux machine? Especially how
> to change the binary (and subdirectories) name to "mcpov" and identify itself
> as such in the copyright notice?
Mac OS X, but Unix is Unix. I had no problems compiling it. I think I might
have had to add the files into the Makefile, but that's just a matter of
editing source/Makefile. Once it compiled a unix/megapov binary, I just copied
it to /usr/local/bin/mcpov, although it might be more proper to edit
unix/Makefile and replace megapov with mcpov. (I'm sure it's more complicated
than that, but that might be a start.) For the copyright, it looks like
there's some stuff in optout.h that might accomplish what you want, although I
just got my mcpov binary and didn't bother with any more details.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> Anyone with experience on setting up MC-Pov on a Linux machine? Especially how
> to change the binary (and subdirectories) name to "mcpov" and identify itself
> as such in the copyright notice?
Man, you're fast! Your head must be spinning with all this radiosity, SSE,
path-tracing and champagne wine... :D
changing the binary name to mcpov:
> mv /INSTALLPATH/whatevername /INSTALLPATH/mcpov
or
> ln -s /INSTALLPATH/whatevername /INSTALLPATH/mcpov
;)
tongue in cheek aside, heed triple_r's advice...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmail com> wrote:
> Man, you're fast! Your head must be spinning with all this radiosity, SSE,
> path-tracing and champagne wine... :D
I' so fast, I actually have come to the point already where I decided that
MC-Pov is not suited to my needs as reference for radiosity. There's too much
that needs to be changed in order to get a scene to work properly with MC-Pov.
Many of the radiosity sample scenes, or scenes I picked as reference, use
conventional light sources, which MC-Pov unfortunately doesn't support. I tried
replacing these with high-ambient spheres, and even designated them as portals,
but I still couldn't get them to affect the scene for yet unknown reasons. Let
alone that it's difficult to decide how bright such a light source replacement
would need to be so that the shot could serve as a reference for my radiosity
experiments. And textures would have to be adjusted, too, as I'd need to
substitute the specular highlights somehow.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> I' so fast, I actually have come to the point already where I decided that
> MC-Pov is not suited to my needs as reference for radiosity.
Hmm, my point is that path tracing in general is more accurate for the lighting
behaviour. The scene as it was supposed to look. So, a render by it should
give you some good guidance for tweakings in the radiosity code to try to match
those expected results...
> There's too much
> that needs to be changed in order to get a scene to work properly with MC-Pov.
That's a shame. OTOH, from previous posts by fidos, it seemed like he basically
just dropped the radiosity and photon settings from a scene and replaced the
light_sources by high ambient objects: the light generated is not merely
diffuse, but also specular, caustics etc. No need for messing with specular
settings in textures or anything. As he used to say, path tracing is very
different from ray tracing...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> That's a shame. OTOH, from previous posts by fidos, it seemed like he basically
> just dropped the radiosity and photon settings from a scene and replaced the
> light_sources by high ambient objects: the light generated is not merely
> diffuse, but also specular, caustics etc. No need for messing with specular
> settings in textures or anything. As he used to say, path tracing is very
> different from ray tracing...
That's exactly the problem: You can't compare the results of MC-Pov with those
of POV-Ray radiosity - because radiosity goes along quite well with the classic
lighting model, whereas MC-Pov does not.
So it's no use as a reference for combined radiosity / classic lighting shots -
which actually make up the bulk of unresolved differences between 3.6 and 3.7.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> So it's no use as a reference for combined radiosity / classic lighting shots -
> which actually make up the bulk of unresolved differences between 3.6 and 3.7.
It's a reference for a more accurate lighting model, to what it'd look like in
the real world. But then again, we already know in the real world lighting
doesn't come through closed corners... :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmailcom> wrote:
> It's a reference for a more accurate lighting model, to what it'd look like in
> the real world. But then again, we already know in the real world lighting
> doesn't come through closed corners... :P
Yup.
And when the light leaks have been stopped successfully, finding out what the
proper color is for "that particular shadow over there" boils down to the
questions what the real world physical properties of "this particular material
over here" and "this particular light source" are supposed to be.
Which is difficult to tell if the material definitions in a scene contain faked
highlights and such, and the light sources are modeled without proper
inverse-of-squared-distance attenuation.
I might use MC-Pov, however, to continue work on my almost-closed-door scene. So
far, it's the most promising renderer for it - if not the only one that has any
chance of coming close to what I'm aiming at.
BTW, I think one of the things to pay attention to in a next-generation POV
version (i.e. 4.0) is to use lighting-model-independent descriptions of
material properties, which each lighting model must then try to map to its own
parameters as best as it can. Parameters that are specific to a certain
lighting model, such as the "ambient" for the "classic" POV lighting, should go
in a separate lighting-model-specific "hint" section (in this particular case I
think it shouldn't be a material-specific property anyway, but an
object-specific one, because it's actually a substitute for indirect diffuse
illumination, which in reality depends on geometry).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> BTW, I think one of the things to pay attention to in a next-generation POV
> version (i.e. 4.0) is to use lighting-model-independent descriptions of
> material properties, which each lighting model must then try to map to its own
> parameters as best as it can.
Sounds cool, but how would you describe any part of the texture in
a lighting-model-independent description? The best you could do is
to define a model as generic as possible (similar to the LightSys
includes?), and derive parameters for simpler lighting models from
there (as done by macros in LightSys). Having this built-in might
someday allow things such as more realistic photons taking the
actual light source spectrum into account.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> > BTW, I think one of the things to pay attention to in a next-generation POV
> > version (i.e. 4.0) is to use lighting-model-independent descriptions of
> > material properties, which each lighting model must then try to map to its own
> > parameters as best as it can.
>
> Sounds cool, but how would you describe any part of the texture in
> a lighting-model-independent description? The best you could do is
> to define a model as generic as possible (similar to the LightSys
> includes?), and derive parameters for simpler lighting models from
> there (as done by macros in LightSys). Having this built-in might
> someday allow things such as more realistic photons taking the
> actual light source spectrum into account.
Okay, maybe I'm a bit too optimistic about this.
However, some stuff in POV's current texture parameter set is redundant: We have
a roughness parameter for phong highlights, another one for specular, yet
another one for MC-Pov's blurred reflections, and yet other people use normal
parameters to define roughness in order to get blurred reflections.
This is because so far, POV has gone the approach to supply separate parameters
for each and every single lighting model out there, which makes it extremely
difficult to move from one lighting mode to the other. I see that as a
drawback.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
