Previous Thread  Next Thread

chat icon Where on earth are the UV source files ?


Posted: Mon May 19, 2003 11:24 pm
Joined: 23 Oct 2002
Posts: 870
Picking at this code gives me a head ache. This file here, needs this file there. .... that file this ......

Could somebody tell me were the UV code files are located in the source.
I can find everything else, like mesh and even S-Mesh.

But no UV.
Reply with quote


Posted: Tue May 20, 2003 3:47 am
Joined: 27 Oct 2002
Posts: 321
Money_YaY! wrote:
Picking at this code gives me a head ache. This file here, needs this file there. .... that file this ......

Could somebody tell me were the UV code files are located in the source.
I can find everything else, like mesh and even S-Mesh.

But no UV.

Interesting the gameengine source is in C++ but blender source is in C..

Do a

fgrep -ri uv * | grep '\.h'

that recursively searches all subdirectories for anything matching "uv" (case insensatively) that contains the text '.h' which assumes we are looking for header files (which contain structures for data) that contain the UV coordinate parameters.. This is assuming th the UV parameters will be called as with the keyword "uv".. If they are not, there is
no choice but to read the code and look for uses of presumed UV coordinates..
Reply with quote


Posted: Tue May 20, 2003 4:21 am
Joined: 23 Oct 2002
Posts: 870
Oh boy , does it ever. A search for uv pulls 400+ slots.
I remembered that I have project builder. And there
are zero files named uv. All of the uv system methods are
strung all over the place { should of know } Mostly in mesh files.
And texture painting is a mystery.
Reply with quote


Posted: Tue May 20, 2003 6:43 am
Joined: 14 Oct 2002
Posts: 80
Some of the UV stuff is in blender/source/blender/src/editface.c
Reply with quote


Posted: Tue May 20, 2003 1:43 pm
Joined: 23 Oct 2002
Posts: 870
Thankyou. Now if you know where Texture Painting is.
That to would help.
Reply with quote


Posted: Tue May 20, 2003 9:45 pm
Joined: 27 Oct 2002
Posts: 321
Money_YaY! wrote:
Thankyou. Now if you know where Texture Painting is.
That to would help.


fgrep -ir texture * | grep -i paint

I was able to find some constant G_TEXTUREPAINT,


$ fgrep -r G_TEXTUREPAINT *

source/blender/blenkernel/BKE_global.h:#define G_TEXTUREPAINT   65536
source/blender/src/poseobject.c:        G.f &= ~(G_VERTEXPAINT | G_FACESELECT | G_TEXTUREPAINT | G_WEIGHTPAINT);
source/blender/src/buttons.c:   } else if (G.f & G_TEXTUREPAINT) {
source/blender/src/space.c:                             if (G.obedit || !(G.f&(G_VERTEXPAINT|G_WEIGHTPAINT|G_TEXTUREPAINT))) {
source/blender/src/space.c:                             else if (G.f & G_TEXTUREPAINT) {
source/blender/src/space.c:                             else if( G.f & (G_VERTEXPAINT|G_TEXTUREPAINT)) sample_vpaint();
source/blender/src/drawmesh.c:          int editing= (G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT)) && (ob==((
ene->basact) ? (G.scene->basact->object) : 0));
source/blender/src/drawobject.c:        vertexpaint= (G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT)) && (ob==((
ene->basact) ? (G.scene->basact->object) : 0));
source/blender/src/drawobject.c:                                int vertexpaint= (G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_
WEIGHTPAINT)) && (ob==((G.scene->basact) ? (G.scene->basact->object) : 0));
source/blender/src/drawobject.c:                        if( G.f & (G_VERTEXPAINT+G_TEXTUREPAINT)) {
source/blender/src/drawobject.c:        if(ob==((G.scene->basact) ? (G.scene->basact->object) : 0) && (G.f & (G_FACESELECT+G_VERTEXPA
source/blender/src/drawobject.c:        else if((G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT))==0) {
source/blender/src/drawview.c:  if(G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT));
source/blender/src/drawview.c:  if(G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT)) {
source/blender/src/drawview.c:  if(G.f & (G_VERTEXPAINT|G_FACESELECT|G_TEXTUREPAINT|G_WEIGHTPAINT)) {
source/blender/src/edit.c:      else if(G.f & (G_FACESELECT + G_VERTEXPAINT + G_TEXTUREPAINT +G_WEIGHTPAINT)) {
source/blender/src/editface.c:  else if((G.f & (G_WEIGHTPAINT|G_VERTEXPAINT|G_TEXTUREPAINT))==0) {
source/blender/src/editmesh.c:  G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT);
source/blender/src/editobject.c:        G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT);
source/blender/src/editobject.c:        G.f &= ~(G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT);
source/blender/src/editview.c:          if(G.f & (G_VERTEXPAINT+G_FACESELECT+G_TEXTUREPAINT+G_WEIGHTPAINT)) allqueue(REDRAWVIEW3D, 0)
source/blender/src/headerbuttons.c:             if (G.f & G_TEXTUREPAINT) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:             if ((!(G.f & G_WEIGHTPAINT)) && (G.f & G_TEXTUREPAINT)) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:             if ((!(G.f & G_VERTEXPAINT)) && (G.f & G_TEXTUREPAINT)) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:             if (G.f & G_TEXTUREPAINT) {
source/blender/src/headerbuttons.c:                     G.f &= ~G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:                             G.f |= G_TEXTUREPAINT;
source/blender/src/headerbuttons.c:     if (G.f & G_TEXTUREPAINT) G.vd->flag |= V3D_TEXTUREPAINT;

Note that G.f seems to be a flag container, the G_TEXTUREPAINT is a
mask, that's why "&" is used to mask off the bits that represent
G_TEXTUREPAINT mode.. I think the "G_" part of the name means
that this is a global state (which have I been saying about global variables, can I say they are evil now?).. So in order to affect the
TEXTURE paint mode you have to locate all the places where the
state is checked to see if its in TEXTUREPAINT mode, then
it performs certain operations on the state.. This means everywhere the
state is check you have to consider these in order to add yoru feature..

The better way to do this would be to put all the texture paint
features in a single object and remove all the condition checking,
as the global state is open to be changed by any code in blender..
And there is no way of enforcing how code in other parts of
blender will change this state information, its relying a lot of the
experience of the coder, which is soooooo wrong.

It would be very easy for me to add G.f =/ 7; and blender's
bit flag would shift in meaning an the state is indeterminate,
because I just took a bit flag and performed a division operation on
it, assuming it was a number and not a bit-flag.. This may not happen intentionally, but what if it was a typo and I was really meaning to say
G.f =& 7? Nobody will find this bug because the syntax is
proper, its the semantics that are wrong and no computer can determine faulty semantics.. That's why we need to document blender's source
immediately and plan a re-design..

It seems that "G" is an effort to localize the scope of the global
flags.. G should have some methods:



so we can do (later once blender is in C++)

if (GlobalState.isInTexturePaintMode()) {
// MyObject is the geometry, texturepaint is a sub-child of the geometry,
// thus we are performing a texturepaint oriented operation
// on the geometry.
// doThisFunction() knows which object this is being performed because
// its being referenced in relation to it..
// who knows what "12,34" are, these are parameters, but
// the method interface for "doThisFunction()" in the "texturepaint"
// sub-child of the Geometry "MyObject" should outline the use of 12,34.

Instead of doing

// mask off the bits the determine the TEXTURE PAINT mode from
// the global state container.. If the result of the mask is greater than
// 0, most C compilers interpret values more than 0 to be a true
// boolean condition, thus the following code is executed.

doThisFunctionOn(SelectedObject, 12, 34, G_TEXTUREPAINT);

// SelectedObject is a void pointer to a structure of unknown size,
// its assumed the first member of this structure is the length of the
// structure, but a check is done to make sure the structure is not a NULL
// pointer. The kind of "doThisFunctionOn" that is performed is determined
// by "G_TEXTUREPAINT" flag, 12 and 34 are the parameters.

The assumption though is that all C compilers assume values more
than 0 to be a "true" state.. What if some C compilers interpret
variables that are stored in Integers to have an extra condition,
where values less than 0 are negative and values above 0 are positive..
And 0 is indetereminate.. Then the assumptions on which the falg checking routines in blender's source are based, will fail.
However a method on an object that checks in plain english for
"isInThisState()" will be easily fixed because the condition checking
code is in a method of an object, its not in every ".c" file throughout
the source code base, I don't have to change every conditional to look like

if ((B.f & G_TEXTUREPAINT) > 0) {

I just change the method "isInTexturePaintMode()" that reveals
the boolean result true or false, without the code that uses it inheriting
from its internal complexities.. This is design, and its purely relevant..

Note in C source "~" mean flip the bits of the given variable.. And
"&=" means mask off and assign these bits..



Means mask off all bits relating to the VERTEXPAINT, FACESELECT, TEXTUREPAINT, WEIGHTPAINT modes.. This is probably a modification made to the global state of blender made when coming out of
some mode that required these flags..

It would have been better just to do


which is probably what its meaning to do.. Or is it


or is it


Who knows.. That code doesn't offer much description..
Reply with quote


Posted: Wed May 21, 2003 3:34 pm
Joined: 13 Oct 2002
Posts: 939
another nice utility besides grep is cscope
You type in a functionname, define etc... and it
tells you all of the files its in. If you haven't
played with it I would give it a try.
Reply with quote

Jump to:  
Powered by phpBB © 2001, 2005 phpBB Group