[Bf-committers] Yafray export problems with images for textures

bf-committers@blender.org bf-committers@blender.org
Tue, 06 Jan 2004 07:57:07 -0600


I hope this list is the appropriate place for this since yafray
export is in its birth stage right now.  If not I'll file a bug
report if that's better.

The yafray export doesn't handle relative pathnames properly.
For example, using an image of //textures/bumpmap.tga leads to
yafray complaining about not being able to find
//textures/bumpmap.tga.  It would be better if the exporter
converted the // syntax in these filenames to the directory
referenced by the //s.

Here's my quick and dirty attempt at a patch to resolve this:
cvs -z3 diff -u source/blender/yafray/intern/yafray_Render.cpp
Index: source/blender/yafray/intern/yafray_Render.cpp
===================================================================
RCS file:
/cvsroot/bf-blender/blender/source/blender/yafray/intern/yafray_Render.cpp,v
retrieving revision 1.2
diff -u -r1.2 yafray_Render.cpp
--- source/blender/yafray/intern/yafray_Render.cpp      5 Jan 2004 15:58:48
-0000       1.2
+++ source/blender/yafray/intern/yafray_Render.cpp      6 Jan 2004 13:53:15 -0000
@@ -333,11 +333,14 @@
                         case TEX_IMAGE: {
                                 Image* ima = tex->ima;
                                 if (ima) {
+                                  char str[FILE_MAXDIR+FILE_MAXFILE];
                                         ostr.str("");
                                         ostr << "<shader type=\"image\" name=\""
<< blendtex->first << "\" >\n";
                                         ostr << "\t<attributes>\n";
-                                       // image->name is full path
-                                       ostr << "\t\t<filename value=\"" <<
ima->name << "\" />\n";
+                                       // image->name is full path, but might
be relative.
+                                       strcpy(str, ima->name);
+                                       BLI_convertstringcode(str, G.sce,
G.scene->r.cfra);
+                                       ostr << "\t\t<filename value=\"" << str
<< "\" />\n";
                                         ostr << "\t</attributes>\n";
                                         ostr << "</shader>\n\n";
                                         xmlfile << ostr.str();



Another issue arises if you've packed an image and it no longer
exists, or maybe never did exist, in your filesystem, those images
also aren't found.  A different issue related to this would be
that your packed image may also be different than the image in
your filesystem if it does exist. This could cause unexpected
differences in how something renders in yafray vs blender
leading to unnecessary bug reports and other user confusion.

Perhaps it would be better to unpack packed images to the yafray
directory and make the references the yafray exporter produces
use those exported images instead.  This would only be done for
packed images.  If implemented, it might be best that this was an
option (on by default) as some images can be large leading to
using much more diskspace than truly needed.

The first issue is more important as it impacts on an important
blender feature that allows users to maintain their .blend files
and resources better.  The second issue is much less of an issue,
but would lead to better and more expected behavior for most users.

--
Todd Koeckeritz, zaz@visi.com

Surfin' the Web with an ActiveX enabled browser is kindof like having
to worry about getting shot everytime you knock on a door.