Oh, good to know, thanks!
And, construct_normals() works perfectly! Turns out it was just not
updating because I wasn't properly updating the Attributes Hash.
Thanks a lot (beer payments are due) :)
Cheers,
Ivan
On Tue, Dec 6, 2011 at 9:03 AM, Jonathan Egstad <jegs...@earthlink.net>wrote:
> It's the angle threshold where normals are broken between faces, but that
> only works for vertex normals. Since only one point normal can exist at a
> single point you can only have smooth normals.
>
>
> On Dec 6, 2011, at 8:51 AM, Ivan Busquets wrote:
>
> Oh, I forgot to ask...
>
> In GeoInfo::construct_normals(), what is the threshold argument for?
>
>
> On Tue, Dec 6, 2011 at 8:48 AM, Ivan Busquets <ivanbusqu...@gmail.com>wrote:
>
>> Thanks Jonathan.
>> I'll have another look at construct_normals. I think I gave that a try as
>> well, but was probably not doing the right thing.
>>
>> With regards to some of those Primitive methods being designed for a Mesh
>> primitive, I did try to use them with a Card, and was still getting nothing
>> out of them. :(
>>
>> Thanks again. I'll give construct_normals a shot and see how it goes.
>>
>> Cheers,
>> Ivan
>>
>>
>> On Tue, Dec 6, 2011 at 8:31 AM, Jonathan Egstad <jegs...@earthlink.net>wrote:
>>
>>> There's an existing method to do this which is pretty fast:
>>> GeoInfo::construct_normals(). I think you need to pre-create the 'N'
>>> attribute and specify the group the attribute is owned by (Group_Points for
>>> your question.)
>>>
>>> The drawback to this method is that is doesn't use any existing normals
>>> it just creates brand new ones.
>>>
>>> Those primitive methods your trying to use likely won't work very well
>>> except for a Mesh primitive as that's the only DDImage Primitive that uses
>>> faces properly. I don't think the Polygon does the right thing. Many of
>>> those methods were created very early on and were not well debugged since
>>> Mesh was the only one to really stress them.
>>> If the Foundry would release a PolyMesh primitive in DDImage that would
>>> likely work much better (hint, hint.)
>>>
>>> -jonathan
>>>
>>>
>>> > My first attempt has been to average the normal vector of all
>>> faces/primitives of which a point is part of. This is what I'm doing (in
>>> pseudo-code):
>>> >
>>> >
>>> > for each point {
>>> > N = (0,0,0)
>>> > for each primitive {
>>> > for each vertex in this primitive {
>>> > prim->build_indices(...)
>>> > check if point index == current point
>>> > if it does: add this primitive's normal to N
>>> > }
>>> > }
>>> > divide N by number of primitives that use this point
>>> > normalize N
>>> > }
>>> >
>>> >
>>> > Now, this works, but it's extremely slow, mainly becauseof the rather
>>> redundant set of loops (looping through all primitives for each point).
>>> >
>>> > In trying to optimize this, I've seen some methods in the Primitive
>>> class that look like they could help, but I haven't been able to get
>>> anything out of them. Particularly:
>>> >
>>> >
>>> > Primitive::get_geometric_normal()
>>> > Primitive::get_face_normal()
>>> >
>>> > Can't get anything out of neither of them. They both return a (0,0,0)
>>> vector. They both take a PointList*. Am I right in assuming I should feed
>>> them the full PointList* for my object as returned by GeoInfo::point_list()
>>> ?
>>> >
>>> > Also tried with:
>>> >
>>> > Primitive::get_vertex_faces()
>>> >
>>> > which is supposed to fill in an std::vector of face indices, but I'm
>>> always getting 0 out of it.
>>> >
>>> >
>>> > Any help on the best approach to compute per point normals would be
>>> greatly appreciated. Also, how are the Primitive methods mentioned above
>>> meant to work? It looks like they could be extremely useful in this case,
>>> but I must be missing a step somewhere.
>>> >
>>> > Thanks,
>>> > Ivan
>>> > _______________________________________________
>>> > Nuke-dev mailing list
>>> > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>
>>> _______________________________________________
>>> Nuke-dev mailing list
>>> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>
>>
>>
> _______________________________________________
> Nuke-dev mailing list
> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
>
>
> _______________________________________________
> Nuke-dev mailing list
> Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
>
_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
