In article <kfK3OIjBjxu=lEMtvnZip=3GMUqx@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Significant reduction of render times can be achieved if complex media
> statements are replaced with precomputed density patterns. My current
> project involves the usage of 200 scattering media statements in a
> single blob container. It takes more than nine hours to render at
> 640x480. If it were a single df3 media, render times could be
> dramatically decreased (by an order of ten to a hundred, depending on
> the scene)

Have you tried the blob pattern/pigments? Those may help...my original 
idea was that they would be good density patterns for media.


> No, because the falloff (for spotlights) would still be circular and
> not polygonal.

Hmm, shouldn't an area light work with projected_through to get that?


> >> : leave original textures when CSGing
> >> 
> >> When performing a CGS difference or intersection, any object with a
> >> non-specified texture is assumed to have a black pigment and ambient
> >> 0. I think a more reasonable behaviour would be to ignore its texture
> >> and use the texture of whatever object the intersection point is in.
> >> Of course this could lead to "coincident interiors" problems but I
> >> think with proper CGSing they can be avoided.
> >
> >Actually, I am pretty sure it uses the default texture, which you can 
> >set with the #default keyword. 
> 
> I guess so, but it still poses the same problem.

> If more then one objects enclose the point, use the texture of that
> one which appears first (or last) in the CSG.




> I didn't mean the user should specify the seed, rather that the seed
> should be constant for each pixel (for example X+Y). This would
> eliminate the "flying pixels" static.

Hmm, that might work...


> I've raised the question of simulating wave properties (wavelength,
> phase and polarization) a couple of times myself but it was
> overlooked. Your idea is certainly more versatile and I see good uses
> for it already.

I actually have a very early version done already. It doesn't work with 
photons(I have to figure out how to get the evaluation point in the 
right part of the code before that will work), and there might be some 
other oddities I haven't found yet, but the straight mapping works. I 
haven't added spherical and cylinderical mappings yet, so it doesn't 
have depth dependant effects yet.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

There are three similar things: Bounding, clipping and the intersection CSG.
They functions are, however, very different and should not be confused.
  What you are talking about, actually, is this:

  intersection
  { object { MyObject }
    object { BoundingObject }
    bounded_by { BoundingObject }
  }

  Since it can be done, and it's very intuitive, it should not be changed.
It should, however, be documented better.
  For some reason I have never had any confusion about these three things.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote...
> The problem with overlapping interiors may or may not be possible to
> be solved by proper CSG. Maybe if the objects are tested in a specific
> order (for example the order they appear in the CSG) and the first
> match is returned, the problem would go away. And yes, only pigments
> would be used, but that should be enough to model things such as

Another possibility would be to use an average of textures, in the same way
as multi-textured blobs or the new vertex-textured meshes.  It would
probably just be a straight average (as opposed to a weighted average) to
avoid any proximity testing (which can be really slow, as we've seen).

Unfortunately, this is difficult to implement currently because of the way
that CSG intersections are handled.  It may not be that bad, though... I'll
have to look at it more closely and let you know.

> >> : polygonal spotlight
> >
> >This is an interesting idea, but couldn't it be done with the
> >projected_through patch?
>
> No, because the falloff (for spotlights) would still be circular and
> not polygonal.

Well, that changes things (and makes them much more difficult to implement).

>
> >> : chop pieces off with bounding
>
> I admit it is probably a bad idea anyway, especially because it would
> duplicate the functionality of the CSG texture patch if it gets
> implemented. [clip] So I am
> proposing both patches because I can't tell right now which one would
> be easier/simlper/safer to possibly implement.

Understood.

> Ditto. Combine this with custom BRDFs and you have infinite
> possibilities.

Custom BRDFs sounds really fun (though they can be slow).

> I've raised the question of simulating wave properties (wavelength,
> phase and polarization) a couple of times myself but it was
> overlooked. Your idea is certainly more versatile and I see good uses
> for it already.

Actually, it wasn't overlooked, just avoided due to perceived complexity.

-Nathan

(I am speaking for myself, not the POV-Team.)

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote...
> : strict variable types

I think that the non-programmers might balk at this.  I like the way that
renderman handles this by linking in to existing languages and thus only
providing core functionality instead of syntax.  However, for good or bad,
POV is not currently heading in that direction.

A minimal amount of stricter variables might be good, but I personally lean
more towards looser variable types.  For efficiency reasons (as you pointed
out), it might be a good idea to allow the user to specify a few
smaller/faster variable types.  But careful attention would have to be paid
to making it easy to use.  Therefore, many paradigms from other programming
languages (C/C++ especially) should not be used because the are not easy to
learn and often difficult to use.  Sure, they might be easy for most of us
in _this_ group, but there will be far more non-programmers who will not
want to have to worry about what type of variable they need to use to get
the precision they want.

Therefore, I would probably just add integer types (maybe char, but most
likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

> : promotion

Promotion is currently automatically done when needed.  I like that approach
better.  Sure, automatic type casting can lead to unexpected results if the
coder doesn't pay attention to what they're doing, but if there the number
of variable types is kept to a minimum, and a logical promotion sequence is
used, then this can greatly ease the task of the coder.

> : hash variables
> For example,
> Posters[155] doesn't tell much while Posters[Peter_Popov] does, and
> they mean the same to the parser.

Current POV code:

#declare Peter_Popov = 155;
#declare ABC=Posters[Peter_Popov];

Maybe what you're looking for is this:
#declare ABC=Posters["Peter_Povpov"];

> : media emission/absorption color map

I agree.

> : patterned turbulence, turbulence_map

I agree.

> : spotlight scale

I'm not quite sure how to code this, but it sounds rather useful.

> : polygonal spotlight

My first thought is to use projected_through.  Do that with an area light
and you get realistic falloff, although I realize that doing such would not
be as fast as what you are proposing.

> : better alpha channel support

I agree.

> : displacement mapping for patterns

Sounds interesting.

> : chop pieces off with bounding

Use CSG.

> : leave original textures when CSGing

Probably won't work as well as you'd expect.  But I don't want to dismiss it
without looking closely.  It is potentially a very useful idea and may not
be as difficult to implement as I am imagining.  I would definately say that
it should be a special option for backwards compatibility reasons.

> : seeded randomness for area_light and aa jitter

As mentioned by Chris, this may not be possible.

> : zero text object thickness

Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
pattern would be better.  This way you could apply the TTF object to another
infinitely thin object (such as a disc) and use filter/transmit to get the
clear part.

> : on error do something useful (skip frame etc.)
>
> OK this one I admit is a bad habit I have from my BASIC years :)

Actually, your example looks quite a bit like an exception-handling block,
and I see a lot of potential usefullness in it.

> : Additional BRDF models

I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
models.

-Nathan

(I speak for myself and not for the POV-Team.)

Post a reply to this message

I have one more suggestion (or the modification of a feature):

  When you write something to, for example, the #warning stream, the given
string is printed there ok.
  However, if you try to print something to the #error stream, nothing is
printed, but the parsing stops and povray shows some lines where the "error"
occurred.
  This is quite useless if you have something like:

#error concat("Expected value between ", str(minval,0,0), " and ",
              str(maxval,0,0), ", but ", str(value,0,0), " was specified.")

  Showing that helps no-one. However, printing that message and stopping
(without showing any source code) would be more useful.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38b81aa4@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Peter Popov <pet### [at] usanet> wrote...
> > : strict variable types
> 
> I think that the non-programmers might balk at this.  I like the way 
> that renderman handles this by linking in to existing languages and 
> thus only providing core functionality instead of syntax.  However, 
> for good or bad, POV is not currently heading in that direction.

Maybe we should make a separate language just for us programmers with a 
converter to .pov files. :-)
Bad idea, I know. Unless there was an editor which automatically 
"compiled" to POV and rendered the scene, it would just be too clumsy a 
system to use. Maybe give POV two different parsers? Or make that 
possible in a later version while rewriting the source?


> A minimal amount of stricter variables might be good, but I 
> personally lean more towards looser variable types.  For efficiency 
> reasons (as you pointed out), it might be a good idea to allow the 
> user to specify a few smaller/faster variable types.  But careful 
> attention would have to be paid to making it easy to use.  Therefore, 
> many paradigms from other programming languages (C/C++ especially) 
> should not be used because the are not easy to learn and often 
> difficult to use.  Sure, they might be easy for most of us in _this_ 
> group, but there will be far more non-programmers who will not want 
> to have to worry about what type of variable they need to use to get 
> the precision they want.

This is true...maybe types aren't such a good idea, even though they 
would be useful in some of the more complex include files and scenes.
However, I would like to see #declare and #local only be used to 
*create* variables, with either another keyword(#let?) or no keyword at 
all required to modify a variable, something like:
#declare K=0;// creates a variable K
#let K=K+1;// adds 1 to the variable K
K=K+1;// adds 1 to the variable K
This would make a lot of the includes easier to read and maintain, and 
would make debugging easier, since it is clearer where a variable is 
first created.


> > : displacement mapping for patterns
> 
> Sounds interesting.

I think the pattern-vector_map approach would be best for this...any 
other ideas?


> > : zero text object thickness
> 
> Sounds good for rendering speed reasons.
> On the other hand, maybe a TTF pattern would be better.  This way you 
> could apply the TTF object to another infinitely thin object (such as 
> a disc) and use filter/transmit to get the clear part.

Something like this? :-)
pigment {
    object {
        text {ttf "crystal.ttf", "my testing text", 1, 0
            translate -z*0.001//to avoid co-incident surface problems
        },
        color White filter 1, color Blue
    }
}
My object pattern was originally a text pattern, it was just more 
versatile to let it use any object.


> > : Additional BRDF models
> 
> I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
> models.

I agree too, now that I have an idea of what one is...but what would a 
good syntax be? And how well would they coexist?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...
> This is true...maybe types aren't such a good idea, even though they
> would be useful in some of the more complex include files and scenes.
> However, I would like to see #declare and #local only be used to
> *create* variables, with either another keyword(#let?) or no keyword at
> all required to modify a variable, something like:
> #declare K=0;// creates a variable K
> #let K=K+1;// adds 1 to the variable K
> K=K+1;// adds 1 to the variable K
> This would make a lot of the includes easier to read and maintain, and
> would make debugging easier, since it is clearer where a variable is
> first created.

Personally, I disagree.  For non-compiled, scripting languages, I like
features such as automatic variable creation and run-time scoping.
I don't like #declare and #local.  I like $ and % instead.  ;-)

$k=0;
$k=k+1;

Run-time scoping, loose variable types, and automatic creation of variables
are 'features' of scripting languages.  This is different from compiled
procedural languages, but 'different' does not necessarily mean 'wrong'.

Finally, because of the way POV's scene-description language is defined,
your example of the assignment with neither #declare or #let would probably
cause ambiguity in the parser, and fixing that would likely lead to
backwards compatibility issues.

See p.t.s-f for an example of run-time scoping.

-Nathan

Post a reply to this message

>I think that the non-programmers might balk at this.

I wouldn't mind if you could make it so that both types of users could work
happily: that is, for POV to support both syntaxes, this way

#declare Whatever = something;

would be just as valid as

#declare Whatever = (int) something;

Of course, this would mean that the programmers would have to be nice enough
to provide dual versions of their files for those who couldn't understand C.
Although, maybe non-programmers wouldn't mind in the case that you had an
include that does something that greatly benefits from these specific
variable types and they had to reason to read the include, just #include it
and enjoy the benefits. Right?

Post a reply to this message

On 26 Feb 2000 13:14:43 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:

>  There are three similar things: Bounding, clipping and the intersection CSG.
>They functions are, however, very different and should not be confused.
>  What you are talking about, actually, is this:
>
>  intersection
>  { object { MyObject }
>    object { BoundingObject }
>    bounded_by { BoundingObject }
>  }
>
>  Since it can be done, and it's very intuitive, it should not be changed.
>It should, however, be documented better.
>  For some reason I have never had any confusion about these three things.

I have not either. Perhaps you have missed my main point, and it is
textures. Imagine you have this:

intersection
{ union
  { sphere { -x, 1 pigment { Red } }
    sphere { x, 1 pigment { Blue } }
  }
  box { <-3,0,-2>, <3,2,2> }
}

Now, there is no simple way to make the surfaces of the spheres that
show up after being chopped off preserve their texture. They get the
texture of the box, which in this example is default or black. If
this:

union
{ sphere { -x, 1 pigment { Red } }
  sphere { x, 1 pigment { Blue } }
  bounded_by { box { <-3,0,-2>, <3,2,2> } }
}

worked in the desired way it would make certain tasks easier. Either
that, or the way CSG works could be modified for the purpose.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

On Sat, 26 Feb 2000 13:22:22 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Therefore, I would probably just add integer types (maybe char, but most
>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

These should suffice, really. And at first I didn't realize the
problems a person with no programming background might run into when
working with unsigned types. You're right, leave'em out.

>> : promotion
>
>Promotion is currently automatically done when needed.  I like that approach
>better.  Sure, automatic type casting can lead to unexpected results if the
>coder doesn't pay attention to what they're doing, but if there the number
>of variable types is kept to a minimum, and a logical promotion sequence is
>used, then this can greatly ease the task of the coder.

I will have to trust you on this one because you're the programmer,
not me :)

>Maybe what you're looking for is this:
>#declare ABC=Posters["Peter_Povpov"];

Yes, of course you're right, a string used as an index is what I had
in mind.

>> : polygonal spotlight
>
>My first thought is to use projected_through.  Do that with an area light
>and you get realistic falloff, although I realize that doing such would not
>be as fast as what you are proposing.

I think Stephan Ahonen was working on such an extension for Blender
(I'll have to check my ICQ message archive). I'll see if I can get him
(or whoever it was who worked on that project) share some source.

>Use CSG.

I'm just giving this idea up because it is not a really good one.

>> : leave original textures when CSGing
>
>Probably won't work as well as you'd expect.  But I don't want to dismiss it
>without looking closely.  It is potentially a very useful idea and may not
>be as difficult to implement as I am imagining.  I would definately say that
>it should be a special option for backwards compatibility reasons.

My heart is filled with hope :)

>> : seeded randomness for area_light and aa jitter
>
>As mentioned by Chris, this may not be possible.

Use the pixel coordinates as a seed and there you go!

>> : zero text object thickness
>
>Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
>pattern would be better.  This way you could apply the TTF object to another
>infinitely thin object (such as a disc) and use filter/transmit to get the
>clear part.

Also, support for '\n' and '\t' in text objects (and for '\t' in
strings) would be useful. Stuff like justification would probably be
overkill (and can be done with a macro anyway).

>> : on error do something useful (skip frame etc.)
>>
>> OK this one I admit is a bad habit I have from my BASIC years :)
>
>Actually, your example looks quite a bit like an exception-handling block,
>and I see a lot of potential usefullness in it.

Really? But that would involve return codes for most operations etc.
Also, what would happen if this block in included, or even worse,
overlaps, a #while..#end, #if..#end or even a #macro..#end block?

>> : Additional BRDF models
>
>I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
>models.

Ditto to that.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message