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
