Re: [K3d-development] Materials & Materials Again

[Timothy M. S. <ts...@k-...>]

Romain Behar wrote:

> I'm trying to get material support back for the OBJ
> reader. There's nothing wrong, but looking at the
> setup_viewport_material() function in material.cpp
> shows that Ambient, Specular, Shininess and Emission
> parameters are hard-coded. Is their support irrelevant
> or just needs implementation?

I started to answer this in detail but it was turning into a book, so I 
put some background information into the Wiki instead:

http://www.k-3d.org/cgi-bin/wiki?ShadingModels

the short answer is that there's no way to figure out how to set those 
parameters based on someone's choice of a RenderMan shader.

> Why are the materials defined per polyhedron and not
> per face as they were previously, while there is a
> material for each patch?

> Al the Gangster from Viewpoint is defined by a single
> polyhderon, and each face has its own color. If we
> were to create a polyhedron for each color, we would
> end up with lots of polyhedra and duplicated points.

Polyhedra are allowed (encouraged, even!) to share points - in fact, any 
of the geometric types within a single mesh can share points.  That 
allows you to, e.g. have a polygon abut a NURBS patch, and edit their 
points without introducing cracks (of course, they don't have to share 
points, if you don't want them to).  So you shouldn't feel that creating 
multiple polyhedra is a bad thing.

Of course that's somewhat peripheral to your question - I chose to move 
away from per-face materials because it had a big impact on our 
inner-loop for previewing polyhedra, and because I felt in hindsight 
that it was of limited value.  Correct me if I'm wrong on this, but I 
don't think Al is a very good example, because he's just a "shell", 
right?  If you were really modeling a character, you wouldn't have, say, 
a shirt polygon with the shirt material connect to an adjacent tie 
polygon with a tie material.  You'd model the tie separately, and place 
it in front of the shirt - they'd be two separate objects entirely, so 
assigning materials to individual faces wouldn't be an issue.  Finally, 
if someone really, really wants to assign materials per-face, it's easy 
to have the UI layer handle the detail of creating a new polyhedron. 
Similarly, doing this in an import plugin should be trivial. 
Last-but-definitely-not-least assigning per-face materials would be 
ignored for subdivision surfaces (in fact, that was the behaviour we had 
in the past - you could assign multiple materials per-face, but if you 
rendered as an SDS, whichever material happened to the the "first" 
material "won").  Because there's no general way of handling this, I 
prefer that modeling code be aware of it from the start.

> Same thing for Uniform Polyhedra which are not colored
> anymore.

Note that materials are not necessarily equal to colors.  A material 
represents a specific set of surface attributes within a specific 
shading model.  You can assign different colors to geometry that shares 
a single material, using the tags mechanism (although we don't preview 
it in the viewport, yet).  My intention is to adopt a subset of standard 
RenderMan tags for our own use, "Cs" in your case:

	k3d::face* const face = ...;
	face->uniform_data["Cs"] = k3d::color(whatever);

... which would assign a single color to the entire face.  If you wanted 
to assign colors to points, which would be interpolated across adjacent 
faces:

	k3d::point* const point = ...;
	point->vertex_data["Cs"] = k3d::color(whatever);

Finally, if you wanted to assign colors to the vertices of an individual 
face, without affecting adjacent faces:

	k3d::split_edge* const edge = ...;
	edge->facevarying_data["Cs"] = k3d::color(whatever);

If you wanted to assign opacities, replace "Cs" with "Os", also with 
type k3d::color.  The other two special names we should use would be for 
textures, "s" and "t", each with type double.

Cheers,
Tim