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
answer.
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?
Cheers
Sebastian
Regards,
Gianni
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68807#68807
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
