 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
This isn't a 'When will the new MegaPOV be released' question... I am in no
hurry.
I was just curious about whether the clever coders out there had thought
about what new features they intended to implement, and if so, if they'd
care to share their thoughts.
Maybe motion-blur will be back.. or post-processing.
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker <big### [at] mariner9 fsnetcouk> wrote:
> Maybe motion-blur will be back.. or post-processing.
Of course there will not be such things...
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ca7749a@news.povray.org...
> Andrew Cocker <big### [at] mariner9fsnetcouk> wrote:
> > Maybe motion-blur will be back.. or post-processing.
>
> Of course there will not be such things...
Does the tone of your reply suggest I asked a ridiculous question? Or have I
misinterpreted your reply?
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Cocker <big### [at] mariner9fsnetcouk> wrote:
>> > Maybe motion-blur will be back.. or post-processing.
>>
>> Of course there will not be such things...
> Does the tone of your reply suggest I asked a ridiculous question? Or have I
> misinterpreted your reply?
I sometimes make too sarcastic replies when I really shouldn't.
The whole purpose of MegaPov is to maintain and make available the different
useful patches made by people. It contains many patches that people have
found useful and which (usually) can't be achieved with the official
povray (at least not in any easy way).
Many of these patches and ideas were implemented in POV-Ray 3.5, but some
others weren't (because they were incomplete, too dirty hacks or for other
reasons). However, I don't see any reason why MegaPov would drop out these
patches once 3.5 comes out and the next version of MegaPov is made from it.
I would be quite surprised if it would. After all, it's these patches which
are the main reason for the existence of MegaPov in the first place. Dropping
them out because they are not in the official version would pretty much make
MegaPov have no reason for its existence. If those patches were dropped out,
then what would MegaPov have besides the official features?
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ca770ab@news.povray.org> , "Andrew Cocker"
<big### [at] mariner9fsnetcouk> wrote:
> This isn't a 'When will the new MegaPOV be released' question... I am in no
> hurry.
>
> I was just curious about whether the clever coders out there had thought
> about what new features they intended to implement, and if so, if they'd
> care to share their thoughts.
>
> Maybe motion-blur will be back.. or post-processing.
Unless I missed something, the motion-blur in MegaPOV is still were it always
was. And so is the post-processing. I don't get how these features "will be
back" if they were never gone...?
You are not confusing POV-Ray 3.5 with MegaPOV here, are you? POV-Ray 3.5 is
*not* MegaPOV. POV-Ray 3.5 includes a few patches also included in MegaPOV
and a lot of similar features that have been completely rewritten from scratch
and are hardly based on other code at all.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3ca82a14@news.povray.org...
> You are not confusing POV-Ray 3.5 with MegaPOV here, are you? POV-Ray 3.5
is
> *not* MegaPOV. POV-Ray 3.5 includes a few patches also included in
MegaPOV
> and a lot of similar features that have been completely rewritten from
scratch
> and are hardly based on other code at all.
Hmmm.. perhaps a slight confusion on my part. Of course, I thought I knew
the difference between POV-Ray 3.5 and MegaPOV, but probably always saw
MegaPOV as a kind of 'test-bed' for the next official POV-Ray... hence when
things were dropped from the official release for various reasons, I suppose
I thought that unless they could be rewritten to be less 'hacks', then they
wouldn't be included in the next MegaPOV. But now you have explained the
reason for MegaPOV's existence, all becomes clear...:-)
So, to get back to my original question... what 'new' experimental features
might we look forward to being implemented?
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> After all, it's these patches which are the main
> reason for the existence of MegaPov in the first
> place. Dropping them out because they are not in
> the official version would pretty much make
> MegaPov have no reason for its existence. If
> those patches were dropped out, then what would
> MegaPov have besides the official features?
Features in MegaPOV were dropped in POV-Ray 3.5 for different reasons. Some
were dropped because they were too incomplete or messy, but others were
dropped for principled reasons, and it was stated that they would never be
included in any future version of POV-Ray (although I don't think the
POV-Team officially said that).
I think post-processing belonged to the latter category. One POV-Team member
said (again, not speaking for the Team) that post-processing was not a job
of the POV-Ray engine, and if it was ever included in POV-Ray, it would be
in a separate engine or executable or something like that.
Now, knowing this, it's certainly not a crazy thought that MegaPOV would be
mostly dedicated to features that actually have a chance of being
implemented in *some* future version of official POV-Ray. An example of
features I'm pretty sure will not return to MegaPOV are the hf_height_at
feature and the feature to center or left align text. It has been clearly
stated that these features were not included in POV-Ray 3.5 because they
were deprecated (is that the right term?).
So indeed, when a person asks if this and that feature will be implemented,
it's not a ridicules question.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> Now, knowing this, it's certainly not a crazy thought that MegaPOV would be
> mostly dedicated to features that actually have a chance of being
> implemented in *some* future version of official POV-Ray. An example of
> features I'm pretty sure will not return to MegaPOV are the hf_height_at
> feature and the feature to center or left align text. It has been clearly
> stated that these features were not included in POV-Ray 3.5 because they
> were deprecated (is that the right term?).
I was speaking about features which can't be achieved by other means.
hf_height_at and text alignments are quite easily achieved by other means
(and aren't there macros in 3.5 for that?).
Post-processing is certainly something which can't be achieved by other
means than the patch, and thus I would be quite surprised if it would be
dropped out. (If it is, many people will certainly complain loudly.)
Motion blur is another example.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3ca8303a@news.povray.org> , "Andrew Cocker"
<big### [at] mariner9fsnetcouk> wrote:
> So, to get back to my original question... what 'new' experimental features
> might we look forward to being implemented?
I would guess not too much is left. A little tweaks here and there and a few
patterns maybe or some new object type also I can't think of any object type
missing. Surely no "big" global features. With radiosity and photons nearly
everything that is state of the art is covered.
Keep in mind that code (and thus the feature it implements) added to a future
MegaPOV is unlikely to be much use for the next official version, which is
POV-Ray 4.0, aka "the rewrite" :-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Keep in mind that code (and thus the feature it implements) added to a
future
> MegaPOV is unlikely to be much use for the next official version, which is
> POV-Ray 4.0, aka "the rewrite" :-)
all the more reason for pov 4 to be developed openly
--
Rick
Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3ca88957@news.povray.org...
> In article <3ca8303a@news.povray.org> , "Andrew Cocker"
> I would guess not too much is left. A little tweaks here and there and a
few
> patterns maybe or some new object type also I can't think of any object
type
> missing. Surely no "big" global features. With radiosity and photons
nearly
> everything that is state of the art is covered.
Well, I'd *definitely* like to see the inclusion of HDRI, and subsurface
scattering if possible. Dunno about the latter, but I think the former is
possible. Also, am I correct in thinking that there is room for improvement
still in the radiosity solving section of POV-Ray.. I think I read it
somewhere on these newsgroups.. although maybe that will have to wait until
POV-Ray 4.
All the best,
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> hf_height_at and text alignments are quite easily
> achieved by other means (and aren't there macros
> in 3.5 for that?).
My point exactly, so those won't be kept in MegaPOV.
> Post-processing is certainly something which
> can't be achieved by other means than the patch
Well, not currently. Still, it has no sight of a future in an official
version of POV-Ray, so IMO it would be better to develop post-processing in
a way which might have a future, i.e. as an external, yet integrated engine.
This may not be what actually happens, but the thought that the current
approach to post-processing will be left out is not that unthinkable.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 2 Apr 2002 14:35:24 +0100, "Andrew Cocker" <big### [at] mariner9fsnetcouk>
wrote:
> Well, I'd *definitely* like to see the inclusion of HDRI, and subsurface
> scattering if possible. Dunno about the latter, but I think the former is
> possible. Also, am I correct in thinking that there is room for improvement
> still in the radiosity solving section of POV-Ray.. I think I read it
> somewhere on these newsgroups.. although maybe that will have to wait until
> POV-Ray 4.
Yeah to subsurface scattering! You can use media, but if you specifically want to use
a thin, single
layer mesh that has no 'interior', media won't work. Not to mention it being
significantly more
complicated to get right.
Another item would be some sort of adaptive smooth mesh. In general getting any mesh
to look good
require either a rediculous number of triangles or the scene being done at sufficient
distance from the
model to 'hide' the flat surfaces. This and the lack of an easy non-media way to do
subsurface
scattering are the main reasons why models noever look real, unless you are using ones
that are very
high quality (like those produced by companies like Dreamworks). So I have wondered
for a while if
some way could be found to create additional subdivisions and smoothing with triangles
whos surfaces
are nearly parallel to the camera direction and are thus most visible. A more complex
model will always
be better, but being very bad at mesh model building and nearly as bad at post work
needed to clean
up the artifacts. Besides with animation you don't generally have the luxery of
checking every frame of
a long animation. A method that could take a realtively small slice of time to
optimize the parts of a mesh
that contain visible problems would be worth it, especially since it is far less
likely to miss something than
the human doing the post work. ;)
Anyway, there are bound to be new things to keep adding.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some kind of pov-like code-based post-processing scripting language would a
nice addition to pov-ray. Especially for more realistic lens-flares.
Lens flares will be really realistic if the inner camera lens reflections
are simulated properly. But that has nothing to do with post-processing of
images.
--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Apache <apa### [at] yahoocom> wrote:
> Some kind of pov-like code-based post-processing scripting language would a
> nice addition to pov-ray. Especially for more realistic lens-flares.
What do you mean "more realistic lens-flares"? I didn't know POV-Ray
supports lens-flares at all.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
>
> Yeah to subsurface scattering! You can use media, but if you specifically
> want to use a thin, single layer mesh that has no 'interior', media won't
> work.
Where should your subsurface scattering stop if you have only a single
layer? The clou with subsurface scattering is that there happens something
to your light _below_the_surface_, right? So there has to be a notion of
"inside" and "outside". That's why you need an object with well defined
inside and outside to get this thing working. The "inside" modifies the
light. That's what "media" does. So, using "media" for subsurface scattering
is natural. (However, "media" should be extended to support other scattering
functions.)
A "thin" mesh doesn't make much sense for subsurface scattering. In
particular, if the mesh is infinitely thin. Then you don't have an
"inside" at all!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> Apache <apa### [at] yahoocom> wrote:
> > Some kind of pov-like code-based post-processing
> > scripting language would a nice addition to pov-ray.
> > Especially for more realistic lens-flares.
>
> What do you mean "more realistic lens-flares"?
> I didn't know POV-Ray supports lens-flares at all.
What do you mean "support"? You can make all kinds of things with POV-Ray
that are not implemented as internal features. That includes lens flares.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> What do you mean "support"? You can make all kinds of things with POV-Ray
> that are not implemented as internal features. That includes lens flares.
If you are talking about the different "lens flare" include files out
there, those are not lens flares. Those are colored discs put on front of
the camera.
A true lens flare would simulate a camera lens and how light behaves with
it. (Something like this *is* possible at least in a limited way, but I don't
think it's very handy. :) )
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Rune <run### [at] mobilixnetdk> wrote:
> > What do you mean "support"? You can make all kinds of things with POV-Ray
> > that are not implemented as internal features. That includes lens flares.
>
> If you are talking about the different "lens flare" include files out
> there, those are not lens flares. Those are colored discs put on front of
> the camera.
> A true lens flare would simulate a camera lens and how light behaves with
> it. (Something like this *is* possible at least in a limited way, but I don't
> think it's very handy. :) )
I recall a thread 3-5 months ago where someone modelled true lens flares
using the photon feature. Don't remember much about it though.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> If you are talking about the different "lens flare"
> include files out there, those are not lens flares.
> Those are colored discs put on front of the camera.
The very concept of ray-tracing is just a faked version of how nature works.
However, it looks nice, so we don't care. The result is what counts.
Likewise with lens-flares. If they look like lens flares, then they *are*
lens flares. I don't see why you define one faked method as being real nut
another as not being real.
> A true lens flare would simulate a camera lens and
> how light behaves with it.
You said the word yourself: "simulate". If it's just a simulation, it's not
real (or "true").
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> The very concept of ray-tracing is just a faked version of how nature works.
> However, it looks nice, so we don't care. The result is what counts.
> Likewise with lens-flares. If they look like lens flares, then they *are*
> lens flares. I don't see why you define one faked method as being real nut
> another as not being real.
There's a difference.
Lighting is based (more or less) in a physical model (eg. the usage of the
cosine as the falloff function for lighting comes from physics). The concept
and implementation of IOR is based on the physical model (the same math
applies). Photon mapping is based in a physical model.
However, faking lens flares with colored discs is in no way based on any
physical model, nor any math from physics is used to make them. They are
just put "somewhere where they look good", without being based on anything.
> You said the word yourself: "simulate". If it's just a simulation, it's not
> real (or "true").
Simulation means (usually numerical) approximation. Since we can't have
infinite accuracy, things have to be approximated and simulated.
However, whether this simulation is based on physical mathematics or
if it's just something "which looks good" but is not based on anything,
makes a big difference.
POV-Ray does not support simulating lens flares. There's no math in POV-Ray
to calculate them. Period.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> POV-Ray does not support simulating lens flares.
> There's no math in POV-Ray to calculate them. Period.
The only one talking about POV-Ray supporting simulating lens flares is you.
Neither Apache nor I used the words "support" or "simulating". I'm simply
saying that you can indeed "make" lens flares in POV-Ray, just like you can
make clouds, fire, bricks, human characters and all other kind of things,
even though they're not "supported" in POV-Ray and can't be "simulated".
If you disagree, feel free to contact Chris Colefax and ask him to rename
his Lens Flare Include File to "Colored Disc Placed In Front Of Camera
Include File". See if he cares.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Mar 19)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
IIRC, Chris Huff said (in this very group) that Post Processing wasn't going to be
included just because it wasn't ready yet.
I never heard about Post Processing being dropped out for principled reasons.
--
Jonathan.
Home: http://digilander.iol.it/jrgpov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Andrew Cocker" wrote:
>
>Also, am I correct in thinking that there is room for improvement
> still in the radiosity solving section of POV-Ray.. I think I read it
> somewhere on these newsgroups.. although maybe that will have to wait until
> POV-Ray 4.
Rumors say there must be some bug in the current implementation causing radiosity
artefacts even with damn high settings. AFAIK nobody figured it out.
--
Jonathan.
Home: http://digilander.iol.it/jrgpov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Apr 2002 22:53:38 +0200, "JRG" <jrg### [at] hotmailcom> wrote:
> Rumors say there must be some bug in the current implementation causing radiosity
> artefacts even with damn high settings. AFAIK nobody figured it out.
What is 'current implementation' in your post ?
current official version is 3.1
current version considering current group is MegaPOV 0.7
current developing version is 3.5 beta 15
In fact currently I render 1000 frames long animation completly with radiosity.
Parts are rendered separately and on different machines. After 200 frames I
don't see any flickering or artefacts. I use "rad_def.inc" from standard distro
with Radiosity_IndoorLQ
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W³odzimierz ABX Skiba" wrote:
> On Wed, 3 Apr 2002 22:53:38 +0200, "JRG" <jrg### [at] hotmailcom> wrote:
> > Rumors say there must be some bug in the current implementation causing radiosity
> > artefacts even with damn high settings. AFAIK nobody figured it out.
>
> What is 'current implementation' in your post ?
> current official version is 3.1
> current version considering current group is MegaPOV 0.7
> current developing version is 3.5 beta 15
>
> In fact currently I render 1000 frames long animation completly with radiosity.
> Parts are rendered separately and on different machines. After 200 frames I
> don't see any flickering or artefacts. I use "rad_def.inc" from standard distro
> with Radiosity_IndoorLQ
I forgot the word 'sometimes'.
BTW, there's no difference between POV 3.5's and MegaPOV's implementation. IIRC
Nathan was pretty clear about it.
--
Jonathan.
Home: http://digilander.iol.it/jrgpov
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:r2rmaus78utvlksqllk96h7dg4gioi56v3@4ax.com...
> What is 'current implementation' in your post ?
> current official version is 3.1
> current version considering current group is MegaPOV 0.7
> current developing version is 3.5 beta 15
>
> In fact currently I render 1000 frames long animation completly with
radiosity.
> Parts are rendered separately and on different machines. After 200 frames
I
> don't see any flickering or artefacts. I use "rad_def.inc" from standard
distro
> with Radiosity_IndoorLQ
Depending on the scene, it's sometimes impossible to get rid of artifacts
completely. Flat expanses of light colour are the usual problem I have
found. On the other hand, I too have used radiosity in animations with no
problems whatsoever.
Andy Cocker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Apr 2002 16:45:02 +0200, Thomas Willhalm <wil### [at] fmiuni-konstanzde>
wrote:
> Patrick Elliott wrote:
> >
> > Yeah to subsurface scattering! You can use media, but if you specifically
> > want to use a thin, single layer mesh that has no 'interior', media won't
> > work.
>
> Where should your subsurface scattering stop if you have only a single
> layer? The clou with subsurface scattering is that there happens something
> to your light _below_the_surface_, right? So there has to be a notion of
> "inside" and "outside". That's why you need an object with well defined
> inside and outside to get this thing working. The "inside" modifies the
> light. That's what "media" does. So, using "media" for subsurface scattering
> is natural. (However, "media" should be extended to support other scattering
> functions.)
>
> A "thin" mesh doesn't make much sense for subsurface scattering. In
> particular, if the mesh is infinitely thin. Then you don't have an
> "inside" at all!
>
Yes well... On the scale of a large object the thickness of the actual portion
of the surface that is A) visible and B) contributes to the scattering is very small,
it
makes no practical sense under such circumstances to fill the entire object with
media. This is especially true if you wanted to use a solid texture 'under' the
surface.
If the thickness of the scattering layer is 1/1000th of the objects total width it is
not practical to make it into a solid mesh with a clear interior. As it is for a
complex
object that did this you would need to place two copies of the mesh, one scaled
slightly smaller and mapped with the main texture, while the other contained the
media. Why double the memory used and use media which is much slower than
a simple simulation that can be applied to a single surface? Never mind the fact that
some shapes may make such scaling complicated or impossible. There are many
situations in which media is absolutely neccessary, but in this case it may be much
slower and more complicated than subsurface scattering really needs to be.
Not everyone that would like to use subsurface scattering can afford the hardware,
time or memory needed to do it the 'right' way. I doubt that someone on a time limit
cares if it is done right, as long as it looks right. A simpler, faster and 'close
enough'
solution would be very helpful. As it is short of coding a patch yourself there really
is
no viable alternative to doing it using media. And I suspect that many of those who
use POV, including myself, are not well equipped to create such a patch.
The arguement seems to be that it can already be done and that the existing method
does it right. I am sure that if we had fast enough computers we could also use real
simulations of tree growth, crystal growth or even molecular structures to 'correctly'
generate the patterns, IOR and color of everything in POV, but is it practical to use
such things even if they are implimented? I would say no. In this case we are asking
for an alternate, and in most cases in which it is likely to be used, far more
practical
alternative. Why is this a bad thing?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
JRG <jrg### [at] hotmailcom> wrote:
> BTW, there's no difference between POV 3.5's and MegaPOV's implementation. IIRC
> Nathan was pretty clear about it.
Yet they produce different images (or at least my early test with the
alpha versions showed this).
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3cab68ab@news.povray.org>, "JRG" <jrg### [at] hotmailcom>
wrote:
> IIRC, Chris Huff said (in this very group) that Post Processing wasn't going
> to be included just because it wasn't ready yet.
Well, if you look at it, there is obviously a lot of work to be done.
Many filters work using pixels as a unit of distance, so they have to be
adjusted for a specific resolution, some of the filters are incomplete
or could be redesigned, the whole processing mechanism could be made
more flexible.
> I never heard about Post Processing being dropped out for principled reasons.
Frankly, it sounds silly. Built-in filters can have access to
information that would be extremely difficult to get to an external
program, such as the actual objects in the scene, and which would be
useless anyway for most image editing programs. Separating them out
would limit their flexibility and needlessly make them more difficult to
use.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> On Wed, 03 Apr 2002 16:45:02 +0200, Thomas Willhalm
> <wil### [at] fmiuni-konstanzde> wrote:
>> Patrick Elliott wrote:
>> >
>> > Yeah to subsurface scattering! You can use media, but if you
>> > specifically want to use a thin, single layer mesh that has no
>> > 'interior', media won't work.
>>
>> Where should your subsurface scattering stop if you have only a single
>> layer? The clou with subsurface scattering is that there happens
>> something to your light _below_the_surface_, right? So there has to be a
>> notion of "inside" and "outside". That's why you need an object with well
>> defined inside and outside to get this thing working. The "inside"
>> modifies the light. That's what "media" does. So, using "media" for
>> subsurface scattering is natural. (However, "media" should be extended to
>> support other scattering functions.)
>
> Yes well... On the scale of a large object the thickness of the actual
> portion of the surface that is A) visible and B) contributes to the
> scattering is very small, it makes no practical sense under such
> circumstances to fill the entire object with media. This is especially
> true if you wanted to use a solid texture 'under' the surface. If the
> thickness of the scattering layer is 1/1000th of the objects total width
> it is not practical to make it into a solid mesh with a clear interior.
So, what you really want is a "thick" triangle. By this I mean a triangle
that creates a second layer on the fly possibly without needing additional
memory. Special variants could be created where the main triangle has the
solid texture and the other sides of your prism are clear. Such a thick
triangle would do what you want.
I'm not sure whether this would really be much faster and produce satisfying
results. But you're right that it's achievable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 05 Apr 2002 10:22:16 +0200, Thomas Willhalm <wil### [at] fmiuni-konstanzde>
wrote:
> So, what you really want is a "thick" triangle. By this I mean a triangle
> that creates a second layer on the fly possibly without needing additional
> memory. Special variants could be created where the main triangle has the
> solid texture and the other sides of your prism are clear. Such a thick
> triangle would do what you want.
>
> I'm not sure whether this would really be much faster and produce satisfying
> results. But you're right that it's achievable.
>
Yeah that may work.. Not sure if it is actually what the developers of the method did.
I think they
upon consideration that they simply simluted the light passing through an outer
surface, reflecting
off something on the inside, then exiting at some unexpected point as a result of
bending, etc. that
occures between the real and faked surfaces.
So your interpretation is a bit more like what I thought than perhaps the original
since you can
declare a surface, scattering and subsurface layers, while the original may assume
that no such
second layer exists. It would still be better than what is now possible, but realism
would be
improved on say human models by adding a second layer capable of showing details like
veins,
etc. I don't believe I saw any indication that this was allowed. But I don't really
have a real clear
understanding of the math involded so didn't pay that close attention to how/if it
could be used in
such a way.
As to if it is faster... Only trying it would tell. However, it has to be at least a
little easier to understand
for those of us who look at media and go, 'Huh!?!'. lol And if it was also faster then
it would make life
a lot easier for everyone where it is applicable.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
