On Apr 20, 2011, at 11:46 AM, Eric Larsen wrote:
> I'm having the same crash trying to create geometry using my own class
> derived from SourceGeo. Are you saying instead of this
>
> Primitive *poly = new DD::Image::Polygon(numSides, true);
> int polyNum = out.add_primitive(obj, poly);
>
> We should be doing this to add polygons?
>
> Primitive *poly = new DD::Image::Polygon(numSides, true);
> int polyNum = out.add_primitive(obj, poly);
> poly = out.writable_primitive(obj,polyNum);
>
Not really - the only reason why you would need to call
GeometryList::writable_primitive() is if you needed to modify an existing
primitive that's already in the stream. The writable calls create locally
cached objects and allow you to modify the local copy rather than the object
cached on a node higher up the tree.
On a SourceGeo there's no nodes above it so you shouldn't need to use that
particular call as GeometryList::add_primitive() already does it internally.
> The same geometry creation code in a GeoReader node doesn't crashes but
> since I have a static filename I could never get the geometry to update so I
> switched to a SourceGeo implementation.
>
> Thanks,
> Eric
>
>
>
> On 04/20/2011 09:19 AM, Jonathan Egstad wrote:
>> Hard to say - the way cached geometry data is passed down the tree is tricky
>> and it's possible the cache pointers are getting trashed somehow -
>> especially if you're directly modifying the GeoInfo without using the
>> GeometryList 'writable' methods. There's management code which synchronizes
>> the geometry data and wraps geometry_engine() so that's probably crashing on
>> a bad pointer. An in-depth discussion of that scheme would take a while...
>> Dynamically adding primitives to a geometry stream should be possible and
>> was intended to be possible, but because a plugin wasn't written that
>> actually did that it likely wasn't tested. Kinda like deleting primitives
>> was never really tested.
>>
>> What's the phrase....'caveat emptor' or something like that...?
>>
>> -jonathan
>>
>>
>> On Apr 19, 2011, at 3:37 PM, Nhat Phong Tran wrote:
>>
>>> Oh I see. By the way, could it be that it makes a difference if I'm
>>> viewing directly the 3D op compared to having the viewer connected to
>>> an Iop further downstream? I wrote a GeoOp plugin which instantiates
>>> geometry over certain points. It works perfectly stable as long as my
>>> viewer is connected directly to the 3D op. If I connect the viewer to
>>> any Iop further downstream, i.e. a ScanlineRender node, then it
>>> crashes as soon as the hash changes. I also set console ouputs to see
>>> where exactly the crash is happening. It seems, that it's not crashing
>>> inside my geometry_engine or my plugin at all. It runs through my
>>> geometry_engine and crashes after. Do you have any idea?
>>>
>>> Thanks,
>>>
>>>
>>> Phong
>>>
>>>
>>>
>>>
>>> On 19 April 2011 15:08, Jonathan Egstad<jegs...@earthlink.net> wrote:
>>>> Btw if you can't preset the primitive sufficiently ahead of time (I had
>>>> this snag with a custom subd primitive) you can set the vertices variable
>>>> in the GeoInfo directly but you'll need to hack the header to get access.
>>>>
>>>> -jonathan
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Apr 19, 2011, at 3:02 PM, Jonathan Egstad<jegs...@earthlink.net> wrote:
>>>>
>>>>> No, just make sure the primitive contains all vert entries - their values
>>>>> don't matter, just the total number of them.
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Apr 19, 2011, at 2:29 PM, Nhat Phong
>>>>> Tran<nhatphong.t...@googlemail.com> wrote:
>>>>>
>>>>>> Does that mean that all the PointList stuff and set(x,y,z) should happen
>>>>>> before add_primitive()??
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------
>>>>>> nhat phong tran
>>>>>> dipl. digital artist (FH)
>>>>>> computer graphics& visual effects
>>>>>>
>>>>>> m_us: +1 (310) 866-6871
>>>>>> m_de: +49 (176) 24 26 34 27
>>>>>> fax: +49 (321) 213 25 866
>>>>>>
>>>>>> santa monica, ca 90401
>>>>>>
>>>>>> sent via iPhone
>>>>>> ----------------------------------------------------------
>>>>>>
>>>>>> On Apr 19, 2011, at 13:30, Jonathan Egstad<jegs...@earthlink.net> wrote:
>>>>>>
>>>>>>> One (of many) details that's not obvious is the accounting of vertices
>>>>>>> inside the GeoInfo and its importance in maintaining any vertex
>>>>>>> attribute arrays. If you add additional vertices to a primitive
>>>>>>> *after* the primitive has already been added to the GeoInfo (via
>>>>>>> GeoInfo::add_primitive()) then vertex attribute array sizes can get out
>>>>>>> of sync possibly causing a crash.
>>>>>>>
>>>>>>> So until that's fixed make sure to completely build your primitive
>>>>>>> first before adding it to the GeoInfo.
>>>>>>>
>>>>>>> -jonathan
>>>>>>>
>>>>>>>
>>>>>>> On Apr 19, 2011, at 11:55 AM, Nhat Phong Tran wrote:
>>>>>>>
>>>>>>>> Well first you need to add an object which holds your primitives (i.e.
>>>>>>>> a polygon) to your output GeometryList. You can do this like this:
>>>>>>>>
>>>>>>>> out.addObject(yourObjectID);
>>>>>>>>
>>>>>>>> Now that you have an object created, you can add your primitives to
>>>>>>>> it, in your case a polygon.
>>>>>>>>
>>>>>>>> out.add_primitive(obj, new Polygon(0, 1, 2, 3));
>>>>>>>>
>>>>>>>> So this allocates a polygon class and assigns points 0-3 to be its
>>>>>>>> vertices. But this doesn't mean that the polygon's shape has been
>>>>>>>> defined yet, because the points 0-3 have not a set position yet. To do
>>>>>>>> this you create a pointer to the pointlist that contains the points of
>>>>>>>> your object, then you need to resize the pointlist to fit all of your
>>>>>>>> primitives points. Then you iterate through the points of the polygon
>>>>>>>> of your interest and set the coordinates of each point.
>>>>>>>>
>>>>>>>> PointList* points = out.writable_points(yourObjectID);
>>>>>>>> points->resize(num_points);
>>>>>>>>
>>>>>>>> for(unsigned int p=0; p<4; p++){
>>>>>>>> (*points)[p].set(x_pos, y_pos, z_pos);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Hope this helps!
>>>>>>>>
>>>>>>>>
>>>>>>>> Nhat
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------
>>>>>>>> nhat phong tran
>>>>>>>> dipl. digital artist (FH)
>>>>>>>> computer graphics& visual effects
>>>>>>>>
>>>>>>>> m_us: +1 (310) 866-6871
>>>>>>>> m_de: +49 (176) 24 26 34 27
>>>>>>>> fax: +49 (321) 213 25 866
>>>>>>>>
>>>>>>>> santa monica, ca 90401
>>>>>>>>
>>>>>>>> sent via iPhone
>>>>>>>> ----------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> On 19 April 2011 09:07, Stephen Newbold<stephe...@moving-picture.com>
>>>>>>>> wrote:
>>>>>>>>> Hi. Anybody know of any easy to understand documentation on how to
>>>>>>>>> create
>>>>>>>>> polygons using the NDK? I had a look through the Sphere.cpp example
>>>>>>>>> that
>>>>>>>>> ships with Nuke and like most things it went completely over my head.
>>>>>>>>> I'm
>>>>>>>>> hoping to be able to create something simple, just a four sided poly
>>>>>>>>> defined
>>>>>>>>> by 4 corner points, but have zero idea on how to go about it.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Stephen Newbold
>>>>>>>>> Senior Compositor - Film
>>>>>>>>> MPC
>>>>>>>>> 127 Wardour Street
>>>>>>>>> Soho, London, W1F 0NL
>>>>>>>>> Main - + 44 (0) 20 7434 3100
>>>>>>>>> www.moving-picture.com
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Nuke-dev mailing list
>>>>>>>>> Nuke-dev@support.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://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>>>>> _______________________________________________
>>>>>>> Nuke-dev mailing list
>>>>>>> Nuke-dev@support.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://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>>> _______________________________________________
>>>>> Nuke-dev mailing list
>>>>> Nuke-dev@support.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://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>>>
>>> _______________________________________________
>>> Nuke-dev mailing list
>>> Nuke-dev@support.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://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>
> _______________________________________________
> Nuke-dev mailing list
> Nuke-dev@support.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://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
