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