On Thu, 2006-10-12 at 11:10 +1000, Drew Whitehouse wrote: > Hi Mark, > > I wondered if that transparent setting had anything to do with things. > Does it make sense to have this for a material that is a simple > non-transparent phong material ? I'm thinking the exporter is being > overly general in this case, we don't really need to set up blending for > a simple material like this ?
It's up to the author of the content to decide what to export. DCC tools and COLLADA support rendering models that don't necessarily translate directly to OpenGL fixed-functionality. > BTW I'm searching for the definition of the "opaque" attribute for > <transparent> and it doesn't seem to be documented in the 1.4.1 > specification. Any pointers ? This is documented in the COLLADA 1.4.1 release notes since the correction was made to the schema after the specification document was produced and ready for publication. If you're interested in tracking COLLADA then you'll want to bookmark www.khronos.org/collada and you can get the relnotes from there too. > Looking at daeRMaterials.cpp, it seems that a bit of refactoring is > necessary to handle this cleanly. Yes it looks that way to me too. The transparent information, from the <transparent> and <transparency> elements, needs to be processed correctly. All the functions are factory methods that build OSG objects, so I guess the transparency has to corrected the materials in a post process or the ordering needs to be changed so that the correct materials are created with consideration of the transparent information. > And I guess this particular situation > needs to be treated as a special case, to obviate the need for a > blending state. It's not a special case, but it is a case. ;) The <transparent> opaque attribute has two values in 1.4.1 (and will have 4 values in 1.4.2 next year most likely) that are: A_ONE and RGB_ZERO. The default is A_ONE and that is more compatible with OpenGL (and RGBA colors and texture usages). The OSG plug-in is hardcoded to handle the A_ONE default case. This test file is using RGB_ZERO for whatever reason. > I notice there is a daeReader::processTransparentType() > method that is going some way towards this. Yes I see that function is only partly processing the <transparent> element. It needs to handle the opaque attribute to do the right job. There also needs to be another function to process the <transparency> element, as those two elements work in combination. Regards, Marcus -- Mark Barnes COLLADA Project Lead, tel:+1.650.655.7342 Sony Computer Entertainment America http://research.scea.com Khronos COLLADA work group chairman _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
