> Because I'm not making any gl calls in my plugin, I'm guessing that either > SourceGeo class or one of its parent classes might be setting some OpenGL > states based on what type of primitive to draw, especially when drawing > polygons, and not restoring the states after that. > > What are your thoughts on that?
I think that either: a) Something in the GeoInfo isn't getting cleaned out properly between filling it with Points and filling it with Polys. From your description it sounds like the vertex count or point count is somehow getting messed up and the wrong attribute information is making its way into the draw code. b) You're not informing the GeoOp hash system that your primitives have changed by modifying the Group_Primitives hash. If that's not happening then it's possible the attributes are being left in a trashed state. Make sure the knob that changes your construction mode is included in the Group_Primitives hash. c) There's a bug in the GeoInfo/Primitive OpenGL drawing code that's not handling the GeoInfo internal change correctly. -jonathan > Jonathan Egstad wrote: >> >>> We basically just told Nuke to draw Polygons or Points, and didn't try to >>> set >>> any OpenGL state using gl calls in our plugins. Nuke must have done that >>> behind >>> the scenes when drawing polygons. Is there any way to know exactly what >>> OpenGL >>> states Nuke has changed? >> >> So I'm not clear on what you mean by 'told Nuke to draw Polygons or Points' >> - do you mean you're doing glPolygon/glPoints OpenGL calls in an Op >> draw_handles() method? Or are you doing gl drawing in a custom Primitive of >> your own? >> >> If you're doing gl calls then you must set all the parameters that may >> affect your drawing otherwise you may be picking up bad states from some >> previous gl calls. Nuke is minimally managing OpenGL, so you can pretty >> easily screw up the OpenGL state for objects that are drawn after yours. >> >> You can test for a whole bunch gl params to figure out the state but there's >> not much point - it's easier to set the obvious ones that affect the kind of >> geometry you're drawing. >> >> -jonathan >> >>> Thanks a lot, >>> >>> -Jean >>> >>> Qin Shen wrote: >>>> >>>> Hi Jonathan, >>>> >>>> Thanks a lot for the tip! I'll give it a try. >>>> >>>> -Jean >>>> >>>> Jonathan Egstad wrote: >>>>> >>>>>> I need to see the points, so I set the Group_Points attribute "Cf" and >>>>>> fill in the Vector4 values with my RGBA. All seems to be good if I >>>>>> don't switch away from displaying Point primitive mode. >>>>>> However, I need to toggle between two modes, the regular Polygon >>>>>> primitive mode or the Point primitive mode. Once I toggle to Polygon >>>>>> mode and come back to Point mode, the displayed points totally go crazy. >>>>>> Not only does the color start to be random, the number of points >>>>>> displayed >>>>>> also goes wacky. Each time a random set of points will be missing. >>>>> >>>>> You're referring to the OpenGL display of Point primitives, correct? Not >>>>> the render output? >>>>> >>>>> Likely the OpenGL state is being left in a bad state from a previous >>>>> object's drawing. Because the order in which objects are drawn can change >>>>> depending on how the user is interacting with the Viewer this can cause >>>>> what you're seeing - random display problems. >>>>> >>>>> One of the aggravations of the OpenGL state engine is needing to set all >>>>> sorts of parameters just in case it's been set by other code you're not >>>>> aware of - there's no 'set to default' functionality. So if some code in >>>>> some plugin sets a parameter you're not expecting to change and your code >>>>> relies on that parameter, your drawing code may be affected. That's why >>>>> it's a good practice to use the glPushAttrib() and glPopAttrib() >>>>> functions to restore the current state of whatever you're meddling with. >>>>> >>>>> -jonathan >>>>> >>>>> _______________________________________________ >>>>> 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
