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);
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
