Implicit function to distance function
category: general [glöplog]
Iq: I'm not exactly sure what to look for (never really used depends.exe before)... It does mention that DWMAPI.DLL is missing, though.
Oh, right. This is Vista only, right? (http://www.processlibrary.com/directory/files/dwmapi/229471 seems to think so at least)
- doesn't work under vista either. nv8600GT, nv175.19 drivers.
- excellent presentation though! Thanks :)
you definitely also need the vc++ 2008 runtime dlls (http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&DisplayLang=en).
and if the vc++ 2008 runtime dll's don't help, install all .net frameworks up to 3.5 (hi mnemonix :)
i would like to point out again how the whole dll situation with the side-by-side assemblies is completely out of control.
oki doki, good point! I'm gonna statically link the CRT crap (otherwise Im using XP and vista, ati and nvidia, sahder 3 and shader 4 everyday so...)
okey, done. It should now work everywhere. Can anybody test again? Thx!
works just fine now, thanks.
I got some stuff going with just ray-marching and bisection so it looks like I'll finish something after all! Thanks m8s.
Quote:
i would like to point out again how the whole dll situation with the side-by-side assemblies is completely out of control.
oh yes... ran into a fine bunch of problems with this already...
me too. That's why I never use "Multithreaded DLL" anymore, but just "Multithreaded".
By thw way, on the presentation you can press some keyds ( "q", "a", "s", "d", "f" for the effects)
By thw way, on the presentation you can press some keyds ( "q", "a", "s", "d", "f" for the effects)
iq: If you have the power to decide that and space/bandwith to distribute those big(ger) files... well...
you mean that it's too big for download? Comment you everyday download ten times that size just watching youtube... Size is not a problem anymore. ALthough you are making intros...
iq: about your article - any ninja-tricks to fix artifacts when doing domain distortion? If I understand this correctly, the procedural distance can (and will) be pretty non-robust for big distortions...
iq: very specific/strange requirements @ work, else I wouldn't care much too...
kusma . i'm not good at maths, but if d(x) is the distance and f(x) de deformation, then d(f(x)) will still give the correct result if f(x) is has a no "domain compression or dilatation".
My intuition tells me this domain compression has something to do with the determinant of the Jacobian of f(x), |J(f(x))| (>1 means expansion, <1 contraction). Im now guessing, but if the determinant is constant, then the method works just fine. For example, affine transformations (scale, rotations, translations) are ok. Even the twist deromation has constant determinant for the Jacobian (proportional to the twist factor). If the |J f(x) | is not constant then we have problems.
Now, for other crazy deformations like noise drivens ones you are right, it introduces errors on the computation. I guess one could correct that by taking the Jacobian into account (or more derivatives). I guess the thing being like y = d(f(x)) , the chain rule should by applied.
Ryg can perhapse go into math details, or I can try tomorrow to write some eqs in paper and see what's the matter.
For the momment, the ninja-trick is probably: as the distance gets smaller (you approach the object), be more carefull on your steps (ie, multiply the computed distance with a distance-dependant-constant). When I'm very close to objects I step in 0.25 times the estimated distance. When I'm far, I just use the estimated disntace cause is similar enough to reality. ... Dissapointed? :)
My intuition tells me this domain compression has something to do with the determinant of the Jacobian of f(x), |J(f(x))| (>1 means expansion, <1 contraction). Im now guessing, but if the determinant is constant, then the method works just fine. For example, affine transformations (scale, rotations, translations) are ok. Even the twist deromation has constant determinant for the Jacobian (proportional to the twist factor). If the |J f(x) | is not constant then we have problems.
Now, for other crazy deformations like noise drivens ones you are right, it introduces errors on the computation. I guess one could correct that by taking the Jacobian into account (or more derivatives). I guess the thing being like y = d(f(x)) , the chain rule should by applied.
Ryg can perhapse go into math details, or I can try tomorrow to write some eqs in paper and see what's the matter.
For the momment, the ninja-trick is probably: as the distance gets smaller (you approach the object), be more carefull on your steps (ie, multiply the computed distance with a distance-dependant-constant). When I'm very close to objects I step in 0.25 times the estimated distance. When I'm far, I just use the estimated disntace cause is similar enough to reality. ... Dissapointed? :)
Now, that sampling problem is easy to solve (at least in brute force), like all sampling problems: sample more (adaptively as I said)
Now, what is worring me a lot more is that many deformations introduce a volume loss or gain. For example, under strong noise deformations, the tentacles of the monster in Slisesix become too thin in some points.
Again just leting intuition fly, this should have something to do with the divergence of the deformation f(x). For affine transforme, again, divergence is zero. For the twisting deformation, the divergence is zero also (there is a nice term cancelation maginc there) (what also makes sense by looking to the field lines of a rotation).
Now, the trick would be to build divergence-free deformation fields. Actually now that I think about it it should not be that difficult :) One can take a random deformation field g(x) and compute it's rotational (f(x) = nabla x g(x) ), that should give a divergence free deformation field and therefor a volume preserving distortion... Hm... Again, those math experts here could confirm this.
Now, what is worring me a lot more is that many deformations introduce a volume loss or gain. For example, under strong noise deformations, the tentacles of the monster in Slisesix become too thin in some points.
Again just leting intuition fly, this should have something to do with the divergence of the deformation f(x). For affine transforme, again, divergence is zero. For the twisting deformation, the divergence is zero also (there is a nice term cancelation maginc there) (what also makes sense by looking to the field lines of a rotation).
Now, the trick would be to build divergence-free deformation fields. Actually now that I think about it it should not be that difficult :) One can take a random deformation field g(x) and compute it's rotational (f(x) = nabla x g(x) ), that should give a divergence free deformation field and therefor a volume preserving distortion... Hm... Again, those math experts here could confirm this.
hmm, let's go through it in turn. for this to work properly, your distance bounds should transform correctly.
affine transformations first: translations are definitely ok. rotations and reflections (orthogonal transforms) too. scaling, depends - uniform scaling probably works, nonuniform scaling most likely won't: your distance bounds correspond to spheres around the current position along the ray. with nonuniform scaling, you distort them into ellipsoids; if your transform expands along the ray direction and contracts along the vector to the closest geometry, your computed step size will be too far (of course, it can also end up too small; that causes a few unnecessary steps but no real harm). via singular value decomposition, you can write any affine transform as A(x)=translate + rotation2*diag(sx,sy,sz)*rotation1*x. (this is not a conventional SVD - i'm constraining the two orthogonal matrices to be rotations but allow negative values in the diagonal matrix; it's more suited to the problem at hand). my guess is that the distance bounds work out whenever |sx|=|sy|=|sz|.
for general (differentiable) transforms, i'd guess that it works out as long as the jacobian for every point has that form, with sx,sy,sz constant everywhere. which boils down to "the rows of the jacobian are pairwise orthogonal and have a constant norm c != 0". again, the pairwise orthogonal is important, otherwise you have shears that can wreak havoc with your distance bounds.
i'm not sure whether this is too pessimistic; but i am pretty confident that any transform that obeys these criteria will work out ok. if your transformation has the |sx|=|sy|=|sz| in one point and is divergence-free, the jacobian should fulfill the requirements everywhere, so that might be the most practical way to check the condition.
affine transformations first: translations are definitely ok. rotations and reflections (orthogonal transforms) too. scaling, depends - uniform scaling probably works, nonuniform scaling most likely won't: your distance bounds correspond to spheres around the current position along the ray. with nonuniform scaling, you distort them into ellipsoids; if your transform expands along the ray direction and contracts along the vector to the closest geometry, your computed step size will be too far (of course, it can also end up too small; that causes a few unnecessary steps but no real harm). via singular value decomposition, you can write any affine transform as A(x)=translate + rotation2*diag(sx,sy,sz)*rotation1*x. (this is not a conventional SVD - i'm constraining the two orthogonal matrices to be rotations but allow negative values in the diagonal matrix; it's more suited to the problem at hand). my guess is that the distance bounds work out whenever |sx|=|sy|=|sz|.
for general (differentiable) transforms, i'd guess that it works out as long as the jacobian for every point has that form, with sx,sy,sz constant everywhere. which boils down to "the rows of the jacobian are pairwise orthogonal and have a constant norm c != 0". again, the pairwise orthogonal is important, otherwise you have shears that can wreak havoc with your distance bounds.
i'm not sure whether this is too pessimistic; but i am pretty confident that any transform that obeys these criteria will work out ok. if your transformation has the |sx|=|sy|=|sz| in one point and is divergence-free, the jacobian should fulfill the requirements everywhere, so that might be the most practical way to check the condition.
Quote:
...computer algebra packages are really powerful tools, but in my experience they're a total bitch to work with...
yeah that's more-or-less true. the main problem is that humans make lots of assumptions unconsciously which the cas' of course cannot make. in practice, you need really lots of painful experience to really be able to exploit a cas. Also, doom(?) mentioned the Maple api, let me spare you the pain, the Maple api *sucks* balls.
As for the actual problem, i'm way too drunken to understand or even read it, maybe tomorrow. Though, i have been drunken for at least 3 weeks straight...
And, ryg writes totally sensible and meaningful sentences, which is a pleasant surprise :)
iq: liked your presentation! always enjoying to read about
your discovered tricks and see how you use them!
(I really want to try some raytracing this semester, seems
like a cool challange)
your discovered tricks and see how you use them!
(I really want to try some raytracing this semester, seems
like a cool challange)
where has old putpixel() gone? :-)
iq: Ok, so the voodoo magic is just being a bit more conservative, fair enough. Thanks a lot, the technique is really interresting! :)
*starts scrambling manically through his math books to understand what the fuck everyone is talking about which is so smart*
