On 14/12/2010 15:10, [GDS|Entropy] wrote:
> I have converted a beta of this to pov 3.7 but it blows up during  
> parse/just before render with an "unspecified error"; this was attempted  
> using only a pigment of <1,1,1> and nothing more complex. No syntax errors  
> encountered. The MegaPov #set keyword is the only non-standard feature  

Can you create a minimal test that replicates this fault and lodge it as a
bug report? (http://bugs.povray.org/).

-- Chris

Post a reply to this message

[GDS|Entropy] wrote:

> It has taken 4 days to render 1 pixel that I am now looking at. :(

no slight intended but somehow this statement made my day.

I can just see you admiring the beauty of this one precious pixel ;)

Seriously, I wonder why the texture has such an immense impact
on your render time. The only cause I can think of is an extreme
recursion because all your snow and ice stuff is probably reflective
and irregularily shaped. But that problem would persist even if you
manage to convert it to a mesh.

Post a reply to this message

Am 14.12.2010 16:36, schrieb Christian Froeschlin:
> [GDS|Entropy] wrote:
>
>> It has taken 4 days to render 1 pixel that I am now looking at. :(
>
> no slight intended but somehow this statement made my day.
>
> I can just see you admiring the beauty of this one precious pixel ;)

Somehow, this picture must be wrong: POV-Ray 3.7 doesn't output single 
pixels ;-)

> Seriously, I wonder why the texture has such an immense impact
> on your render time. The only cause I can think of is an extreme
> recursion because all your snow and ice stuff is probably reflective
> and irregularily shaped. But that problem would persist even if you
> manage to convert it to a mesh.

But then the intersection test /might/ be faster -- or not. Until he has 
tested it, it's difficult to tell.

Another possible speed killer I see is that - unless I'm missing 
something somewhere - the algorithm for "fusing" the blob textures is as 
follows:

- Look up all the blob elements affecting the given intersection point, 
and add their respective texture & weight to a list (*).

- Walk through the list, computing the effective color at the 
intersection for each single texture independently (includes reflections 
& refractions).

- Compute a weighted average of the effective colors.

Note that if the blob is very "dense", with many blobs affecting any 
given point of the surface, this will give a huge list of textures & 
weights, which is /not/ filtered for duplicates. Such a 
duplicate-removal step at (*) might speed up rendering tremendously.

A mesh-based version with a "baked" "texture weighting map" would not 
suffer the same problem.

Post a reply to this message

clipka wrote:

> Somehow, this picture must be wrong: POV-Ray 3.7 doesn't output single 
> pixels ;-)

as far as I can tell he didn't yet get the macro to work with 3.7 ;)

> Note that if the blob is very "dense", with many blobs affecting any 
> given point of the surface, this will give a huge list of textures & 
> weights, which is /not/ filtered for duplicates.

Hmm ... but I expect to provoke this problem you need to assign
individual textures to each component, so with one snow/ice texture
applied to a blob it would be ok?

--
Zen for renderers: If a single pixel gets rendered in the forest,
but no one is there to see, does it get anti-aliasing?

Post a reply to this message

Am 14.12.2010 21:00, schrieb Christian Froeschlin:

>> Note that if the blob is very "dense", with many blobs affecting any
>> given point of the surface, this will give a huge list of textures &
>> weights, which is /not/ filtered for duplicates.
>
> Hmm ... but I expect to provoke this problem you need to assign
> individual textures to each component, so with one snow/ice texture
> applied to a blob it would be ok?

Yes; but as he's talking about the problem of reproducing the "blobbing" 
of textures if moving to a mesh-based version, I presume he does assign 
individual textures.

If only one of the textures is transparent, it might be worth trying to 
assign the transparent texture to the blob as a whole, and the 
non-transparent texture(s) to individual blob elements.

Post a reply to this message

Of course; I will work on isolating the exact SDL responsible and will  
create a bug for it once I have accomplished this.

Ian

On Tue, 14 Dec 2010 09:10:53 -0500, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:

> On 14/12/2010 15:10, [GDS|Entropy] wrote:
>> I have converted a beta of this to pov 3.7 but it blows up during
>> parse/just before render with an "unspecified error"; this was attempted
>> using only a pigment of <1,1,1> and nothing more complex. No syntax  
>> errors
>> encountered. The MegaPov #set keyword is the only non-standard feature
>
> Can you create a minimal test that replicates this fault and lodge it as  
> a
> bug report? (http://bugs.povray.org/).
>
> -- Chris


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

That makes sense; as I continue with this effort I will keep this in mind.

Thanks!
Ian

On Tue, 14 Dec 2010 07:40:07 -0500, clipka <ano### [at] anonymousorg> wrote:

> Am 14.12.2010 05:05, schrieb [GDS|Entropy]:
>> Interesting...quite interesting.
>>
>> I wonder though; no matter the non-blob approach taken, it seems that
>> when considering the textures, if one were to have two blobs of
>> differing texture they would no longer "mix" as they do with blob
>> objects. If this is the case then a lot of the realism gained through
>> slope textures+blobs would be lost.
>
> You could do a render with the different textures replaced by simple  
> pigments "red 1", "green 1" and "blue 1", respectively. The resulting  
> data could be used as a basis for a texture_map to apply to the mesh via  
> UV mapping.


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

On Tue, 14 Dec 2010 11:41:16 -0500, clipka <ano### [at] anonymousorg> wrote:

> Am 14.12.2010 16:36, schrieb Christian Froeschlin:
>> [GDS|Entropy] wrote:
>>
>>> It has taken 4 days to render 1 pixel that I am now looking at. :(
>>
>> no slight intended but somehow this statement made my day.
>>
>> I can just see you admiring the beauty of this one precious pixel ;)

And I did. :P
Reminds me of the old days on a 166mhz with 24mb ram lol! :)

>> Seriously, I wonder why the texture has such an immense impact
>> on your render time. The only cause I can think of is an extreme
>> recursion because all your snow and ice stuff is probably reflective
>> and irregularily shaped. But that problem would persist even if you
>> manage to convert it to a mesh.
>
> But then the intersection test /might/ be faster -- or not. Until he has  
> tested it, it's difficult to tell.
>
> Another possible speed killer I see is that - unless I'm missing  
> something somewhere - the algorithm for "fusing" the blob textures is as  
> follows:
>
> - Look up all the blob elements affecting the given intersection point,  
> and add their respective texture & weight to a list (*).
>
> - Walk through the list, computing the effective color at the  
> intersection for each single texture independently (includes reflections  
> & refractions).
>
> - Compute a weighted average of the effective colors.
>
> Note that if the blob is very "dense", with many blobs affecting any  
> given point of the surface, this will give a huge list of textures &  
> weights, which is /not/ filtered for duplicates. Such a  
> duplicate-removal step at (*) might speed up rendering tremendously.
>
> A mesh-based version with a "baked" "texture weighting map" would not  
> suffer the same problem.

You nailed it!
I stopped the render, 4 day pixel and all (which was at the interface of  
two textures), applied an ice texture to the whole thing (instead of  
per-blob), and now its rendering very quickly. I will post the thing when  
it is done.

Now, the only thing is, this really nukes the beautiful transitions  
between the slope snow texture and slope ice texture...I suppose I can  
live with this for now.

There *really* needs to be some optimization to the blob/texture code...

Now, speaking of the marching triangles, I found this on Stack Overflow:  
http://stackoverflow.com/questions/3894283/adaptive-implicit-surface-polygonization
Check out the link (direct PDF link) from the bottom:  
http://vimmi.inesc-id.pt/publication.php?publication_id=107

That paper looks useful, and from reading it (if I comprehend it all  
properly), a lot of what this needs can be accomplished with trace() and  
outside() in combination with min/max_extent(). Some of the math I would  
need to look up (Hessian matrices..I could use a dx/dy refresher as well),  
but I think I understand what this is doing. I could see this being very  
simple to implement in C#, but I cannot speak for SDL. I will read over  
this paper more, look up what I need to, and give it a go using SDL within  
the next week.

Ian

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message

[GDS|Entropy] wrote:

> Reminds me of the old days on a 166mhz with 24mb ram lol! :)

Old? My 5th computer had 166mhz *sigh* :-P  It felt much faster
than any later system due to being slightly overpowered for dos 6.2 ;)
It's still sitting under my desk.

Post a reply to this message

The one I mentioned was my second. My first was an old Unisys running some  
weird dos-like OS with 3 frames and I have no idea what it was called. :P

Ian

On Thu, 16 Dec 2010 15:28:20 -0500, Christian Froeschlin <chr### [at] chrfrde>  
wrote:

> [GDS|Entropy] wrote:
>
>> Reminds me of the old days on a 166mhz with 24mb ram lol! :)
>
> Old? My 5th computer had 166mhz *sigh* :-P  It felt much faster
> than any later system due to being slightly overpowered for dos 6.2 ;)
> It's still sitting under my desk.


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Post a reply to this message