Is this limit in 3.7? If so, WHY?

>>>>>> Parse Error: There are more than 1000000 components in a blob.<<<<<<
Total Scene Processing Times
   Parse Time:    0 hours  0 minutes  0 seconds (0 seconds)
   Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
   Cloth Time:    0 hours  0 minutes  0 seconds (0 seconds)
   Mechsim Time:  0 hours  0 minutes  0 seconds (0 seconds)
   Render Time:   0 hours  2 minutes 49 seconds (169 seconds)
   Postpr. Time:  0 hours  0 minutes  0 seconds (0 seconds)
   Total Time:    0 hours  2 minutes 49 seconds (169 seconds)
CPU time used: kernel 0.47 seconds, user 138.11 seconds, total 138.58  
seconds

POV-Ray finished

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

On 27/12/2010 10:29, [GDS|Entropy] wrote:
> Is this limit in 3.7? If so, WHY?

Why not? There has to be a limit somewhere. One million components is that
limit. Which is no different than 3.6. Or 3.5. Or even 3.1 for that matter.

> 
>>>>>>> Parse Error: There are more than 1000000 components in a blob.<<<<<<
> Total Scene Processing Times
>    Parse Time:    0 hours  0 minutes  0 seconds (0 seconds)
>    Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
>    Cloth Time:    0 hours  0 minutes  0 seconds (0 seconds)
>    Mechsim Time:  0 hours  0 minutes  0 seconds (0 seconds)
>    Render Time:   0 hours  2 minutes 49 seconds (169 seconds)
>    Postpr. Time:  0 hours  0 minutes  0 seconds (0 seconds)
>    Total Time:    0 hours  2 minutes 49 seconds (169 seconds)
> CPU time used: kernel 0.47 seconds, user 138.11 seconds, total 138.58  
> seconds
> 
> POV-Ray finished
>

Post a reply to this message

Is this something we could be allowed to set via ini file?
Could the limit be increased?
Was there a specific reason for a 1mil limit, or was it arbitrary?

It would be nice for these things to be constrained only by the amount of  
available memory.

That limit really puts a hamper on what I am doing...

On Sun, 26 Dec 2010 18:42:42 -0500, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:

> On 27/12/2010 10:29, [GDS|Entropy] wrote:
>> Is this limit in 3.7? If so, WHY?
>
> Why not? There has to be a limit somewhere. One million components is  
> that
> limit. Which is no different than 3.6. Or 3.5. Or even 3.1 for that  
> matter.
>
>>
>>>>>>>> Parse Error: There are more than 1000000 components in a  
>>>>>>>> blob.<<<<<<
>> Total Scene Processing Times
>>    Parse Time:    0 hours  0 minutes  0 seconds (0 seconds)
>>    Photon Time:   0 hours  0 minutes  0 seconds (0 seconds)
>>    Cloth Time:    0 hours  0 minutes  0 seconds (0 seconds)
>>    Mechsim Time:  0 hours  0 minutes  0 seconds (0 seconds)
>>    Render Time:   0 hours  2 minutes 49 seconds (169 seconds)
>>    Postpr. Time:  0 hours  0 minutes  0 seconds (0 seconds)
>>    Total Time:    0 hours  2 minutes 49 seconds (169 seconds)
>> CPU time used: kernel 0.47 seconds, user 138.11 seconds, total 138.58
>> seconds
>>
>> POV-Ray finished
>>
>


-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

On 27/12/2010 10:48, [GDS|Entropy] wrote:
> That limit really puts a hamper on what I am doing...

you're welcome to build your own binary.

Post a reply to this message

Yes, that would work...but only for me. I am making a macro for general  
consumption.

But given your response I see there is essentially no hope of changing  
this in any way.
As a fellow software developer I understand; low request features/changes  
which are not bugs are not very high sprint priorities.
As a user, it sucks, and I was actually surprised that there even was such  
a limit.

I will adaptively disable the portion of code responsible for generating  
the mass of extra components; while not an optimal solution, it is a  
solution none the less.

I would like to thank you and the rest of the pov team for your continued  
development; I would not be where I am today were it not for pov-ray. :)

Merry Christmas!

On Sun, 26 Dec 2010 18:52:48 -0500, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:

> On 27/12/2010 10:48, [GDS|Entropy] wrote:
>> That limit really puts a hamper on what I am doing...
>
> you're welcome to build your own binary.


-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

On 27/12/2010 11:06, [GDS|Entropy] wrote:
> Yes, that would work...but only for me. I am making a macro for general  
> consumption.
> 
> But given your response I see there is essentially no hope of changing  
> this in any way.

Not four days before release, no. If you'd brought this up a month ago it
might be different.

Post a reply to this message

Am 27.12.2010 01:06, schrieb [GDS|Entropy]:

> I will adaptively disable the portion of code responsible for generating
> the mass of extra components; while not an optimal solution, it is a
> solution none the less.

Alternatively, you could just start another blob when you hit that 
limit; you'll get an artifact /somewhere/, but maybe you can work around 
that, or just hope nobody will notice.

For instance, you could use one blob for the icicles, and difference 
away another blob (or multiple of them) for the air bubbles.

Post a reply to this message

Oh...wow...four days! :D :D :D

By the way, something which was changed between beta 39 and 41 fixed the  
"uncategorized error" I encountered with my snow macro a few weeks ago.

As always, thanks pov team!

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

On Sun, 26 Dec 2010 19:35:22 -0500, clipka <ano### [at] anonymousorg> wrote:

> Am 27.12.2010 01:06, schrieb [GDS|Entropy]:
>
>> I will adaptively disable the portion of code responsible for generating
>> the mass of extra components; while not an optimal solution, it is a
>> solution none the less.
>
> Alternatively, you could just start another blob when you hit that  
> limit; you'll get an artifact /somewhere/, but maybe you can work around  
> that, or just hope nobody will notice.
>
> For instance, you could use one blob for the icicles, and difference  
> away another blob (or multiple of them) for the air bubbles.

Different blob objects was a problem I faced last year, given two blob  
objects won't blob together, realism was substantially lost. Now it is a  
single blob object filled with nested loops.
At any rate, a 3.7 compatible sanity-check Alpha will be released in a few  
hours, minus the air bubble functionality.

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> There has to be a limit somewhere. One million components is that
> limit.

  Why one million? A physical limit in 32-bit machines, even if you use
signed indexes, would be a bit over 2 billion.

-- 
                                                          - Warp

Post a reply to this message