[osg-users] different materials for a geometry and highlight

Sebastian Messerschmidt sebastian.messerschmidt at gmx.de
Wed Sep 28 04:52:35 PDT 2016

Am 9/28/2016 um 1:25 PM schrieb Gianni Ambrosio:
> Hi Sebastian,
> after looking at your example I understood a shader is not needed, right?
Exactly. It is one of the possible solutions. I have not fully 
understood your problem though.

> The solution you suggest is to apply a texture instead of changing color. In my case the image of the texture would be a monochromatic image.
I don't get the monochromatic part ... Currently I left out any vertex 
colors and define the color with the texture only.
> If all that is correct, then I have few questions.
> I modified my previous example to insert your solution there.
> 1) Since most part of the road surface may be not associated to a "material", then I thought of adding a BIND_OVERALL default grey color. Does it make sense?
Not really, the texture in this example maps to all triangles, so there 
is no color needed. The mapping is uniform, linear and non-repeating to 
have an addressable element.
> 2) On the basis of point 1) is it possible to add a texture only to triangles affected by a "material". In your example you added a texture to the overall geometry. Isn't that a problem if the road has a bunch of vertices? I mean, that bunch of vertices would be duplicated to create texture coords.
What would this safe you? Effectively in my example you wouldn't need 
more than 4 vertices and still can "edit" the colors. As long as I don't 
understand your data-set it is impossible to give you a more elaborate 
> 3) In the attached example Ididn't understand how to set the image just to the picked triangle so that it will be shown of the "current" color. (In my example pushing 1,2,3 and 4 keys changes the current color).
The image spans the whole set .. As I said, it is one way to go. The 
mapping is simply there to map a texture coordinate to a position in the 
mesh. The tex->getImage(0)->setColor(selectedColor, tc); should work 
fine, if the texture coordinates are correct.

> 4) I have to read some documentation about textures since I didn't understand how texture coords should be defined and the effect of:
> 	texture->setFilter(osg::Texture::MIN_FILTER, osg::Texture::NEAREST);
> 	texture->setFilter(osg::Texture::MAG_FILTER, osg::Texture::NEAREST);
Try LINEAR and see the difference. It basically prevents neighboring 
pixels from being affected.
> 5) I tried to create different texture coords (see #ifdef in the attached code) but "result.getTextureLookUp(tc);" in "doUserOperations" method does not seem to work. Anyway even with your implementation of "buildTexCoords" the selection is pretty odd.
What isn't working? My original example should work, with a slight 
offset in the picking. This is due to pixel center issues and can be 
solved by manually calculating the offset. I simply had no more time to 
make it nice...
I had a quick peek at your source: You only define 4 texture 
coordinates, where you need one per vertex .... Try to load a texture 
from file to test your coordinates

Again: You cannot share all edges really when you need to have 
per-triangle properties. You might use vertex colors with flat-shading, 
but I don't know the expected result: Does it need to look good or is it 
simply some graphical representation?


> Regards,
> Gianni
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68807#68807
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160928/6398cc77/attachment-0003.htm>

More information about the osg-users mailing list