obj2mesh, UV coordinates and image aspect

radiance-general
1

This time I have a question about UV mapping:

I tried to export UV texture coordinates from Blender and used
the example from the manpage of obj2mesh to define a texture:

        void colorpict tiled_pat
        7 red green blue mytile.pic . frac(Lu) frac(Lv)
        0

        tiled_pat plastic tiled_mat
        0
        5 .9 .9 .9 0 0

        tiled_mat mesh tiled_mesh
        1 mymesh.rtm
        0

The man page says this works for square images. My image was
a rectangle at first and was converted to a square later, but
both images had the same (wrong) look. I have uploaded two
images (one from Blender, one from rpict) to illustrate the
difference.

http://home.arcor.de/tbleicher/blender/bliff/current.html

My questions now are:

1) What went wrong?
2) How would I define a non-rectangulare image texture?

Please not that I have not checked the quality of the generated
UV coordinates. They are generated by a established *.obj exporter
for Blender and I think they are correct for now. My understanding
of the Radiance texture mapping options is so bad that I expect
the error in the texture definition.

Thanks and have a nice weekend,

Thomas

2

Hi Thomas,

If you're using the blender uv editor, try to have a look at the
function exportRadianceMeshOBJ here:
http://cvs.savannah.nongnu.org/viewcvs/brad/brad/brad/brad_radiance.py?r
oot=brad&view=markup

I remember having similar problems and having fixed them with this
check:
w,h = img.getSize()
if w>h:
   objfile.write("vt " + str(uvco[0]*(float(w)/float(h))) + " " +
str(uvco[1]) + "\n")
else:
   objfile.write("vt " + str(uvco[0]) + " " +
str(uvco[1]*(float(h)/float(w))) + "\n")

I then use:

void colorpict facematerialbasename
7 red green blue facematerialbasename.pic . Lu Lv
0
0

Hope to have understood your problem, and that this helps.

Ciao,

F.

···

____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses

3

I remember having similar problems and having fixed them with this
check:
w,h = img.getSize()
if w>h:
   objfile.write("vt " + str(uvco[0]*(float(w)/float(h))) + " " +
str(uvco[1]) + "\n")
else:
   objfile.write("vt " + str(uvco[0]) + " " +
str(uvco[1]*(float(h)/float(w))) + "\n")

Thanks for the hint. I mad a few tests with different images
and found that the exported UV coords are always in the range
(0,1) for _both_ dimensions. I think this is the common range
for UVs in all CG applications except Radiance. Here we have
coords range (0,1) for the smaller dimension and (0,l/s) for
the larger, so above 1 for all non-square images.

As a result the texture image area is croped to the lower left
square of the image. Your code multiplies the coords for the
larger side with the image aspect (>1!) to cover the whole
image in Radiance texture space. I'll have to go that way, too,
(no big thing for a dedicated Radiance exporter) but I wish
there was a way to define the texture with the right image aspect
so any uv enabled *.obj file could be mapped correctly without
rewriting the coords.

void colorpict facematerialbasename
7 red green blue facematerialbasename.pic . Lu Lv
0

Just checked the meaning of 'frac()' and I think Lu/Lv is in
fact the better choice for uv coord mapping than frac(Lu/Lv).
The vertices do not have to cover the whole image after all.

Hope to have understood your problem, and that this helps.

Yes. Another step closer to Blender world domination.

Thomas

···

On 20.02.2006, at 10:39, Francesco Anselmo wrote:

4

Hi Thomas,

If the problem is really just the fact that you have non-square images, this is easily remedied in your Radiance description. If the horizontal dimension in your image is larger -- say 1.5 times the vertical dimension, you would use a (0-1) range for each of u and v like so:

        void colorpict tiled_pat
        7 red green blue mytile.pic . Lu*1.5 Lv
        0

        tiled_pat plastic tiled_mat
        0
        5 .9 .9 .9 0 0

        tiled_mat mesh tiled_mesh
        1 mymesh.rtm
        0

-Greg

5

Hi Greg. Thanks for that solution.

Hi Thomas,

If the problem is really just the fact that you have non-square
images, this is easily remedied in your Radiance description.
If the horizontal dimension in your image is larger -- say 1.5 times
the vertical dimension, you would use a (0-1) range for each of
u and v like so:

       void colorpict tiled_pat
       7 red green blue mytile.pic . Lu*1.5 Lv
       0

This is what I was after in the first place. I tried exactly
this version in an earlier version of my description but I could
not see any effect. So I messed with the uv coords directly.

Now I've tried it again after your affirmation and - voila -
image mapping as desired. (I think I had an additional material
definition somewhere in the scene during my first tests that
redefined all my manual changes so they never had any effect
I could see.)

Thanks again. I knew it had to be something simple like that.

Thomas

···

On 20.02.2006, at 17:24, Gregory J. Ward wrote:

6

Interesting thing - I recently started using Blender 2.41 (from 2.37) and I hadn't gotten around to reinstalling b/rad. So I downloaded the latest and copied brad.py into the ./blender/scripts folder and cp -R copied the "brad" directory into the ./blender/scripts directory as well, per the install instructions. Now, when I go to Blender's "Scripts" interface to update the menus, the only scripts that appear in the scripts menus are the ones that are alphabetically before brad.py, (brad is not included). As soon as I rm brad.py and the brad directory, the Blender Scripts menu is back to normal, with all of the available scripts as before.

Any thoughts on why this happens? if I manually load brad.py in Blender (into the test window) from the Scripts directory and then Alt-P (well, Option-P on the Mac) I get a console error telling me: ImportError: No module named brad_i18n - etc.

Mac OS X 10.4.4, G4 dual 1.25, Blender 2.41, Python 2.4 - brad.py is Rev 1.8 from Aug 11, 2005 (from CVS) and the rest is from brad 0.1b. The same thing happened with the brad.py file original 0.1b release, etc.

Thomas - pretty neat interface to brad from within Blender - I'm interested to see how this turns out.

Thanks,

kirk

···

------------------------------

Kirk L. Thibault, Ph.D.
[email protected]

p. 215.271.7720
f. 215.271.7740
c. 267.918.6908

skype. kirkthibault

7

Interesting thing - I recently started using Blender 2.41 (from 2.37) and I hadn't gotten around to reinstalling b/rad. So I downloaded the latest and copied brad.py into the ./blender/scripts folder and cp -R copied the "brad" directory into the ./blender/scripts directory as well, per the install instructions. Now, when I go to Blender's "Scripts" interface to update the menus, the only scripts that appear in the scripts menus are the ones that are alphabetically before brad.py, (brad is not included). As soon as I rm brad.py and the brad directory, the Blender Scripts menu is back to normal, with all of the available scripts as before.

Any thoughts on why this happens? if I manually load brad.py in Blender (into the test window) from the Scripts directory and then Alt-P (well, Option-P on the Mac) I get a console error telling me: ImportError: No module named brad_i18n - etc.

Hi Kirk.

I know Francesco did not have much time to keep b/rad in sync with
Blender development. I expect that the problems with the menu
are the result of a failed "import" of brad. The bundled scripts
are tested with Blender 2.41, brad is not.

I made b/rad work recently with an explicit "brad_path" setting.
I have made a few changes to the original file as well but i don't
think they are important.

As first step try to set "brad_path" to the directory where you
keep the "brad.py" and the "brad" directory, i. e.

brad_path = "/Users/kirk/blender/scripts/"

(around line 101 in brad.py; line count may differ but it is well
commented). That did the trick for me on OS X 10.4.4, Python 2.3.

Mac OS X 10.4.4, G4 dual 1.25, Blender 2.41, Python 2.4 -

When your at Python 2.4 I think you know your way around Python
and OS X. Keep an eye on the imports in the script. If they fail
any error message could be the result. Perhaps add

try:
     import ...
except ImportError, err:
     print "ERROR", err

to the import section to check this explicitly.

brad.py is Rev 1.8 from Aug 11, 2005 (from CVS) and the rest is from
brad 0.1b. The same thing happened with the brad.py file original
0.1b release, etc.

I got my version sometime after September 2005 from Francesco's web
site (tar ball, not CVS).

Thomas - pretty neat interface to brad from within Blender -
I'm interested to see how this turns out.

Me too :wink:

You can download the snapshots here:

http://home.arcor.de/tbleicher/blender/bliff/download.html

There is no tutorial and they are not tested much. I have not
yet separated the brad parts from the GUI toolkit so it's one
download. The zip file is fresh and contains today's texture
mapping update.

Don't get frustrated,

Thomas

···

On 20.02.2006, at 21:12, Kirk Thibault wrote:

8

I manually changed the brad_path at line 101 and it worked. Hot diggity dog. Thanks Thomas!

kirk

···

------------------------------

Kirk L. Thibault, Ph.D.

On Feb 20, 2006, at 3:42 PM, Thomas Bleicher wrote:

As first step try to set "brad_path" to the directory where you
keep the "brad.py" and the "brad" directory, i. e.

brad_path = "/Users/kirk/blender/scripts/"

(around line 101 in brad.py; line count may differ but it is well
commented). That did the trick for me on OS X 10.4.4, Python 2.3.