I assume it's fairly straightforward, because raytracers do this all the time. But never having written a raytracer myself...
Just thinking out loud here... You could take the normalized crossproduct of a vector from a surface point to the camera with the normal (in that order), and the normalized crossproduct of the normal with a vector from the point to the light (again in that order), and take the dot product of the two results. Values near 1 mean that the 3 vectors are more-or-less coplanar and the camera and light are on opposite sides of the normal, values near 0 mean that they are not coplanar, and values near -1 mean that the camera and light are on the same side of the normal. So that gives you a value you can use to modulate the strength (although you'll need to handle the case when 2 or all 3 of the vectors are colinear as a special case). After that you'd need to compare the difference between the angle between the normal and camera and the angle between the normal and light, and implement a falloff based on that difference. Just some thoughts... gray P.S. For transforming normals you should use the transpose of the inverse not the inverse of the transpose. I wrote it wrong below. From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Van de Lagemaat Sent: Friday, April 27, 2012 01:53 PM To: softimage@listproc.autodesk.com Subject: RE: Evaluating ice weight map gen per frame Thanks Graham, it's all changed now anyway. I'm trying to scatter a bunch of objects in an area that is centralized around the highlight of a light (null attached) and am using a weight map to adjust the particle density in that area. I forgot to take into account the fact that the highlight position needs to take into account both the camera and the null instead of just the null. Any ideas on how I would need to modify my tree to achieve this? From: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: April-27-12 8:34 AM To: softimage@listproc.autodesk.com Subject: RE: Evaluating ice weight map gen per frame I just realized you can get away with a lot fewer calculations if you just convert the null's position to the sphere's reference frame. You just need to multiply null.kine.global.pos by the inverse of sphere.kine.global, then you can get rid of all the other coversions. gray From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Van de Lagemaat Sent: Thursday, April 26, 2012 07:47 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame I'm sure I'll be calling you again :-) I'm having some issues with the instances on my sphere changing orientation when the sphere rotates. If I can't get it working by tomorrow I'll post an example. From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: April-26-12 4:36 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame Glad to help :) From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Van de Lagemaat Sent: Thursday, April 26, 2012 07:33 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame That did the trick good sir! From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: April-26-12 4:06 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame I suspected there might be normals involved. When converting reference frames of "true" vectors as opposed to positions, you need to treat them differently (i.e. ignore any translation). There are a few ways to do this e.g.: - Plug sphere.global.kine.ori and .scl into SRT to Matrix, plug that into a 3x3 matrix (to force the data type), and use that to multiply the normals before the dot product. - Convert the normals to 4D vectors with W=0, multiply them by sphere.global.kine as before, and convert back to 3D vectors before taking the dot product. Note that the above works for "true" vectors in general but normals are even more special. If there's any possiblity that there might be non-uniform scaling involved, then instead of just using sphere.global.kine you need to plug it into a Transpose node and then an Inverse node first. That's not necessary for uniform scaling because in that case the inverse of the transpose is the same as the original matrix. And all the above applies only to vectors and normals, not positions. Good luck! gray From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Van de Lagemaat Sent: Thursday, April 26, 2012 06:39 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame I kludged this together from wathcing a tutorial on something unrelated to weight map gen but it seems to work :-) I'm in no way experienced with ICE so I'm sure I'm messing something up. From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: April-26-12 3:29 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame No, they should work. Can you post a screengrab or scene? gray From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Van de Lagemaat Sent: Thursday, April 26, 2012 06:21 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame Thanks Graham! I can now get transform changes on the sphere working but orientation changes to the sphere still seem to be borked. I'm guessing that the orientation values aren't included in all of this? From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Grahame Fuller Sent: April-26-12 2:42 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: RE: Evaluating ice weight map gen per frame Use Multiply Vector by Matrix to multiply sphere.PointPosition by sphere.kine.global first. Then calculate the dot product. When you get attributes like Sphere.PointPosition by explicit reference (i.e. not reading at locations), you get the raw values, which are expressed relative to the object centre. Multiplying by the global transform converts to them to the global reference frame. gray From: softimage-boun...@listproc.autodesk.com<mailto:softimage-boun...@listproc.autodesk.com> [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Simon Van de Lagemaat Sent: Thursday, April 26, 2012 05:27 PM To: softimage@listproc.autodesk.com<mailto:softimage@listproc.autodesk.com> Subject: Evaluating ice weight map gen per frame I'm generating a weight map on a mesh using a simple dot product of a null and the surface points on the sphere. When I animate the sphere the weight map generation is ignoring the transforms and acting as if the mesh is in a rest state. How can I get the weight map tree to eval the mesh and its transforms on every frame? I created a simulated ice tree but no luck. Cheers
<<attachment: winmail.dat>>
