Reader XI and Vertex Colors

Question

Hi all,
in Reader XI vertex colors aren't multiplied with diffuse colors anymore, like in previous reader versions.
Instead diffuse colors are replaced by vertex colors when used.
Vertex colors with diffuse textures still work fine.
Greetings,
Chuck

Answer 1

Dave Merchant wrote:
... in a math-model scenario where vertex colors represent a fourth parameter on a 3D surface, it is absolutely proper that the VC-generated texture ignores lighting, so the true 'value' is displayed.
Remember that only VC-colored surfaces behave this way - if you want some part of a scene reacting to lighting and shadows, don't give that node any VCs.
If a 3D surface ignores lighting, the three other parameters (x,y,z) become hard to assess.
Compare the examples
http://www2.iaas.msu.ru/tmp/test_texture.pdf and http://www2.iaas.msu.ru/tmp/test_vertex_color.pdf .
When you move around the model, it is much easier to get the shape of the surface when it responds to lighting.
In VC case it is impossible to see if the mono-colored end of the tube is open or closed, for example.
The stability and simplicity of VCs are really valuable features (for example, the textured model looks differently in Software and OpenGL renderes, while the VCed one looks the same), but mandatory ignoring of lighting is more of a disservice in the interactive viewer, where user is expected to be able (with default GUI) to change camera position, lighting and (with JavaScript or view dictionaries) move parts of the model around.
On the other hand, this thread started with complaint about how Adobe does _not_ care about the stabilty of results achieved with VCs. So 3D PDFs can not be relied upon as the only way to convey important color information in any case (but can serve as an additional tool, esp. for insruction). There is a long way from PDF-E to PDF-A.
As not giving node VCs - it is possible if you control the whole drawing block of an application.
If you try to create a PRC or U3D output driver for an existing program, you may find that driver API deals with VCed primitives. And such design is quite reasonable, since the authors of the built-in OpenGL viewer of such a program did RTFM glColorMaterial, so know how to drive both diffuse and emissive color with VC.
PS. My _guess_ is that logic has nothing to do with the support for vertex colors in Adobe 3D viewer.
I suspect that when Adobe U3D viewer was first introduced, it was based on Right Hemisphere 3D viewer, that did not support VCs, so minimal VC support was hacked in, just to have some. The introduction of PRC could not change much, since even in the PRC format spec VCs look like an afterthought. And we are going live with that ad hoc code, since declared commitment of Adobe to open 3D standards is not translated into action when it comes to allocating 3D programmers time (if they still have any such programmers left). /* Hope to be wrong. */