 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> It's actually 100. It can be changed, but it'll probably still be hard-coded
> to some value. In your test code, your rays must be missing some of the
> smaller spheres and/or boxes.
>
Is it hard-coded from the beginning, or can it be changed with some global-setting?
Obviously (since I tried) max_trace_level has no effect...
Does the actual error occurr, if all objects that overlap would create a surface
(like when using intersection{})?
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 02 Jan 2002 21:37:59 +0100, Tim Nikias wrote:
>>
>> It's actually 100. It can be changed, but it'll probably still be hard-coded
>> to some value. In your test code, your rays must be missing some of the
>> smaller spheres and/or boxes.
>>
>
> Is it hard-coded from the beginning, or can it be changed with some global-setting?
> Obviously (since I tried) max_trace_level has no effect...
>
> Does the actual error occurr, if all objects that overlap would create a surface
> (like when using intersection{})?
The error occurs when a ray finds that it's already inside of 100 objects and
is about to enter a 101st. The number of objects is hard-coded and can't be
changed by the scene file or by an INI option.
One possible fix for your problem is to not specify 100% transparency and to
use a sensible adc_bailout. Whether that will work for you depends on the
scene, of course.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Check if "bounded_by" will help for your scene.
atb,
gleb
> this may be changed somehow (and if yes, then how). I thought
> about implementing a check into the algorithm which avoids the
> problem...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm. So much for creating an animation using MILLIONS OF TRANSPARENT MEDIA OBJECTS!
;)
Ah well, I'll find one solution or another, but thanks for giving away a dark little
secret of POV-Ray... ;)
Perhaps it could be mentioned somewhere in the docs for advanced-users or such, like
"Not-so common scene pitfalls" or such.
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 02 Jan 2002 10:48:38 +0200, Peter Popov <pet### [at] vip bg> wrote:
>I know this may sound stupid but anyway... are you sure the 'union'
>statement is outside the while loop?
Scratch that, it seems like you've hit an internal limit... somewhat
like max_intersections, but not quite, it's the maximum number of
nested objects a ray can be in (99 or 127, IIRC).
A solution? Well, try to avoid that at parse time, i.e. incorporate
some collision detection algorithm so that the particles do not nest
that much. Or use a blob instead of a union.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias wrote:
>
> Hmm. So much for creating an animation using MILLIONS OF TRANSPARENT MEDIA OBJECTS!
Not really. There is nothing wrong with animating millions of objects.
Animating millions of objects nested inside of each other is, well,
just plain silly.
:^}
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C3371BA.C7B39EAF@gmx.de>, Tim Nikias <Tim### [at] gmxde>
wrote:
> Hmm. So much for creating an animation using MILLIONS OF TRANSPARENT MEDIA
> OBJECTS!
Hmm...would it help to merge the objects? It would depend on how your
media is set up...it wouldn't work very well if you are relying on the
objects to contain the media. Another thing that may help would be to
put multiple medias inside one object.
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Animating millions of objects nested inside of each other is, well,
> just plain silly.
Nope. Imagine animating millions of objects, and COINCIDENTALLY, they overlap!
A particle-system is also meant to use thousands of objects for major effect, for what
else? (okay, I am being a little pushy) ;)
Also, my main problem was concerned with about 200 objects, not millions of em... ;)
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am relying on the objects as containers for the media (in most cases, they are
spherical media), but I also thought that somehow using one container with
hundreds
of media might be possible (though difficult to handle interval- and
sampling-wise).
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C348A9B.6F280CE1@gmx.de>, Tim Nikias <Tim### [at] gmxde>
wrote:
> I am relying on the objects as containers for the media (in most
> cases, they are spherical media), but I also thought that somehow
> using one container with hundreds of media might be possible (though
> difficult to handle interval- and sampling-wise).
Well, if you are using MegaPOV or the 3.5 beta, you should be able to
use the object pattern to contain the media.
--
--
Christopher James Huff <chr### [at] maccom>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
