Hi Paul, The loaders should all attach a default colour to osg::Geometry they generate, if they don't this should be added.
Perhaps one workaround would be to have a custom visitor to patch osg::Geoetry without any colours or normals. You can create scene graphs completely validly without colour but only if lighting is always on, and the colour material is set to off. Also with normals you need them when lighting is on, but not needed when lighting is off. The general rule though is if you add both colours and lighting then at worse you are carrying around redundent data. Robert. On 11/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Don? Robert? Anyone? Any other thoughts on this? This seems to be a minor, but real problem associated with mixing loaded and dynamically created geometry in a scenegraph. It sounds like there are two solutions is proposed: 1) Go through the Loaded Geometry and make sure that each of the loaded geometries gets a vertex color attached to it. This seems a crude solution at best since it seems to me that loaded geometry (which has attached material) should stand "on it's own". 2) Build dynamic geometry with a StateSet and a Material rather than a vertex, primitive or overall color bind. Which seems a more elegant solution, but will it work? So what would be anyone's recommendation on this -- or is there a third solution that I am not thinking of? - Paul > We have a similar problem but sounds like the same cause. We initially > load some > geometry that has NO MATERIALS or vertex colors. We then dynamically add > colored > geometry (has per vertex colors) to the graph. The originally loaded > geometry > then switches colors to the last vertex color of the dynamically loaded > geometry. > We've tried a couple of simple solutions for solving this but none have > worked. > We tried using a shader on the intially loaded geom and found that the > incoming > glColor (instead of being uncolored) was still the last last vertex color > of the > dynamically loaded geometry. That lead me to think that state wasn't being > tracked properly. > (see www.vrac.iastate.edu/~biv/dynamic_color_problem/) > initially_loaded_geometry.jpg -- the inital geom > added_geometry_1.jpg -- 1st added geometry > added_geometry_2.jpg -- 2nd added geometry > > One thing to note is that the initial geometry goes transparent in this > case but > we've also run our app w/o making the initial geometry transparent and > we've > seen the same thing. > > I was thinking of writing some kind of "material/color state pusher/popper > visitor" class but I didn't see a clear path for this and it seemed kinda > like a > "hack",obviously ;) > biv > > >> Hmm, well maybe I am not explaining the problem too well. Here is >> another >> way of explaining it. >> >> 1) I load files. They have materials on them. >> 2) I also create nodes dynamically. They have bound colors. >> 3) When the dynamic geometry is drawn BEFORE the loaded geometry, then >> the >> color of the dynamic geometry shows up in the loaded geometry (and on >> down >> the scenegraph) until the next color is set with a bound color. >> 4) When the dynamic geometry is drawn AFTER the loaded geometry, then >> the >> problem does not occur. >> >> You suggested that the problem could be resolved by setting a bound >> color >> to each of the loaded files. So, essentially after loading the file, go >> in >> to the geom of the loaded file and set a bound color to the geometries. >> >> My question was whether or not it would be easier to set a material in >> my >> dynamically created geometry some other way (not with a color bind) so >> that the color state would automatically "pop" as I traversed the >> scenegraph. >> >> Does that make sense? >> >> Dumping the model to an OSG reveals what I think it does. Namely that >> there is a color on the dynamically created geom and not on the loaded >> geom. >> >> - Paul >> >> > Hi Paul, >> > >> > I'm afraid there a few too many unknowns for me to point you to the >> > solution. I'd recommend writing out the model to .osg and then >> > browsing through it to see if everything is where you expect it to be. >> > >> > Robert. >> > >> > On 11/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> Hi Robert, >> >> >> >> So when I load a model (from an obj converted to an ive) with a >> material >> >> associated with it, doesn't that solve the problem for me? Well >> >> obviously >> >> it doesn't, but why not? Do I need to go through each of the loaded >> >> models >> >> and check them after they are loaded to ensure that there is a color >> >> binding for them? Isn't there an easier way? Like I said, the problem >> >> model does have a material. Is it a difference between using the >> >> material >> >> in the loaded file and a color binding in the dynamic model? I can >> >> certainly create a material to use for the dynamic model instead of >> >> doing >> >> color binding if that is better. >> >> >> >> - Paul >> >> >> >> > HI Paul, >> >> > >> >> > You need to a make sure all your osg::Geometry have a colour array >> >> > attached, otherwise colours will bleed into one another. >> >> > >> >> > Robert. >> >> > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
