Would it be possible to squeeze in an object keyword that removes 
that object from all radiosity calculations?  If this would take a lot of 
extra code, then by all means it doesn't belong in 3.5, but if it's a 
simple thing it's something I would really like to see make it in.  I have 
a scene with multiple isosurfaces that do not benefit much (if at all) by 
radiosity, but the rest of the scene really needs it.  The isosurfaces 
really slow down the render when radiosity is used though.

-- 
Rich Allen
(Remove SPAM from my address to reply by e-mail)

Post a reply to this message

How about tracing the scene without Isosurfaces, save the
radiosity, and then load it when tracing with Isosurfaces?
I don't know if that would be accurate enough for you
purposes, but it may be a solution.

Rich wrote:

>         Would it be possible to squeeze in an object keyword that removes
> that object from all radiosity calculations?  If this would take a lot of
> extra code, then by all means it doesn't belong in 3.5, but if it's a
> simple thing it's something I would really like to see make it in.  I have
> a scene with multiple isosurfaces that do not benefit much (if at all) by
> radiosity, but the rest of the scene really needs it.  The isosurfaces
> really slow down the render when radiosity is used though.
>
> --
> Rich Allen
> (Remove SPAM from my address to reply by e-mail)

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

That might not work.  Imagine what would happen if the isosurfaces were
mirrors!

As I remember the code, it would not be difficult at all to modify the
lighting.c code to implement this feature.  This object flag would just
modify whether the ra_gather function was called or not.  The problem
would be associated with adding a keyword and token, which is quite a
trial with the way that the parser functions as of 3.1g.

Personally, I think it is a WONDERFUL idea and should be implemented
ASAP, but that's just my $0.02.

- Ben

Post a reply to this message

> The problem
> would be associated with adding a keyword and token, which is quite a
> trial with the way that the parser functions as of 3.1g.

???  Adding a keyword to the parser is really trivial.  Just take a look at
the many patches available - they had no problems doing it.  Anyway, the
whole thread is off-topic in this group...

    Thorsten

Post a reply to this message

Well, I was talkin about isosurfaces not contributing to the scene, and
with no need of them being lit much by the scene either.

Ben Birdsey wrote:

> That might not work.  Imagine what would happen if the isosurfaces were
> mirrors!
>
> As I remember the code, it would not be difficult at all to modify the
> lighting.c code to implement this feature.  This object flag would just
> modify whether the ra_gather function was called or not.  The problem
> would be associated with adding a keyword and token, which is quite a
> trial with the way that the parser functions as of 3.1g.
>
> Personally, I think it is a WONDERFUL idea and should be implemented
> ASAP, but that's just my $0.02.
>
> - Ben

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3cc90781@news.povray.org: 

> ???  Adding a keyword to the parser is really trivial.  Just take a
> look at the many patches available - they had no problems doing it. 

I've tried the trick mentioned earlier, rendering without the isos, saving 
the radiosity map, then re-rendering with the isos.  The two-step process 
takes longer than to just render the whole scene with radiosity, especially 
since the parts of the scene that DO need to react with radiosity change 
often while I'm experimenting.  <smile>  The scene looks different enough 
without radiosity that I need to render with every few changes.  <sigh>

> Anyway, the whole thread is off-topic in this group...

Sorry!  I don't see a feature-request group, and this is the only 
discussion group fro 3.5, so I went with it.  Where should I be posting 
these kinds of messages?

-- 
Rich Allen
(Remove SPAM from my address to reply by e-mail)

Post a reply to this message

Rich <SrP### [at] ricoswebcom> wrote:
> Sorry!  I don't see a feature-request group, and this is the only 
> discussion group fro 3.5, so I went with it.  Where should I be posting 
> these kinds of messages?

  povray.general, povray.newusers, povray.advanced-users or
povray.unofficial.patches, depending on the contents. Perhaps even
povray.programming if it's something really related to the povray source
code.

-- 
#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