Hello Enrico,
Enrico Borrione wrote:
> While working on texture coordinates, i came across a problem:
> using cylindrical and spherical textures i can't find a way to
> avoid the singularity problem in the texture wrapping area.
> The only solution i could think about was the vertex splitting
> where the texture starts, so there are a series of vertices with
> texcoord 0, and a copy of them with texcoord 1 overlapping and making
> the texture melt correctly where the singularity lays.
from the little I know about tex coord generation I'd imagine there are
two problems:
1) a vertex is on the seam (where the edges of the texture meet) and
thus should have texture coordinate 0 for one face and texcoord 1 for
another one. This can be solved either by using different indices for
positions and texcoords or by duplicating the vertex.
2) a face crosses the seam. To get smooth texturing such a face would
have to be split such that it has an edge (and thus 2 vertices) that are
on the seam.
> Now I looked at the starting guide where it talks about geometry, indexing,
> and primitives, but I still can't get a very clear idea on how indexing
> works in OpenSG.
Yeah, it's a bit tricky. Can you try to identify concrete problems you
have, otherwise I'd end up repeating the information from the starting
guide ;)
> Right now i am using a FaceIterator to sweep along the scene and spot which
> faces
> cross the singularity area. The next step will be finding the vertices
> crossing it and
> splitting them between the two triangles on the opposite sides.
>
> In pseudo code it would be like:
>
> 1) find the crossing face (done)
> 2) find the crossing vertex (almost done)
Do you mean edge here ? I'm not sure I understand this, since a vertex
is a point it can either be on the seam or to either side of it.
> 3) make a copy of the vertex
> 4) change the index in the faceiterator so that it points to the new vertex
Hm, I usually think of the PrimitiveIterator and its derived classes as
similar to vector<>::const_iterator. They do not allow you to modify the
geometry and doing so while an iteration is in process can invalidate
the iterator (It is possible if you know what you are doing, but a bit
difficult to describe. I think, "it is safe to modify primitives that
follow the one corresponding to the iterators position" comes close -
*no* guarantees of course).
> 5) try to make the process easy to invert (since i would like to update
> texture
> coordinates often, i'd like to melt again the vertices before applyng this
> algo again).
Could you explain, why you'd like to recompute the coordinates ? Would
it be possible to keep some of them (e.g. along the textures edges)
fixed to avoid the problematic cases ?
> Keeping aside the multi indexing for the moment (i'd like to get it straight
> the single indexing first) I don't seem able to find a funcion
> osg::FaceIterator::setPositionIndex that allows me to change on the fly the
> topology of the primitives in the geometry core.
Yes, they are not intended to allow modifications of the geometry, thus
they only support read access.
The OpenSG data structures are not really geared towards this use, so
they tend to not provide the information you are looking for (or at
least not convenient and/or efficiently).
Hope it helps, feel free to ask more questions,
Carsten
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
