> -----
> From: Alan Purvis
> Sent: Sunday, August 20, 2006 12:53 PM
>
> > the button(s) you pushed in Blender.
>
> Press alt-z with the cursor over the 3D view.
Aaaaaah! Thank you Alan. This opens the window on a whole new
understanding of Blender's texture handling. Apparently, there are three
different ways to put a texture on something in Blender:
A. Assign a textured material to an object.
B. Assign a textured material to a mesh, or part of a mesh.
C. Somehow vaguely associate a texture with an object, using the "UV Face
Select" + "UV Editor" + "Image Open."
Amazingly, only this option C has any consistent effect on what gets
exported, to either the .osg or .dae formats. It also has the most effect
on what is shown in Alt-Z rendering mode. To make things worse, Blender
actually lets you do (A/B) and (C) at the same time, so an object can have
multiple, conflicting textures!
Jan gives a good description of this confusing, unlikely and undocumented
way of applying a texture:
> From: Jan Ciger
> Sent: Sunday, August 20, 2006 1:55 PM
>
> Select the object you want to map the
> texture to (in object mode), switch to UV mapping mode. In
> the UV editor you should see the object unwrapped. Select all
> faces (hit 'A'). Then I have just changed the image file
> using the list box in the UV editor to show the correct image
> and that's it. The same for the other object.
Yow. Yes, it's almost usable... once you know it.
> > When you render them in OSG, the poles do not even appear.
>
> I see the poles just fine as red.
I am sorry, i can't see how it is "just fine" that the poles are textured
(either transparent or red) since 1. The poles aren't textured and 2. They
have a grey material on them. Red is a big bug.
> The problem lies in bogus texture coordinates for the poles:
> 5.6051938573e-45 1.12103877146e-44 - all the texture
> coordinates on the poles are like this - invalid.
The problem is bigger: the fact that both texture, and texture coordinates,
are written at all, for an object that has _no_ texture coordinates, or
texture, in the Blender scene. Remember i pointed out the failure in your
.osg output:
> > name "Pole2"
> > Geode {
> > StateSet {
> > textureUnit 0 {
> > Texture2D {
> > file "stop128.png"
The 'pole' objects do not have any texture, not by method (A) (B) or (C)
above. If Blender + exporter can't write an untextured object as
untextured, then it's really not a usable art path.
Roger wrote:
> This observation is not in any way a criticism of this code, it is
> open source so you either work within the boundaries of what someone
> else has written or get your hands dirty!
Yes. The question becomes - is it even possible to fix/workaround in
osgexport? I will try. Or do we have to join the Blender coding team to
fix it from that side?
Jan writes:
> BTW, did you see some of the exporters available for 3DS Max or Maya?
> That is sometimes black magic and complete voodoo to get to work right
Unfortunately i know exactly what you're talking about. It's only after
years of holding out hope for MAX+various exporters, including OSGExp, that
i finally gave up on that broken mess and tried Blender+osgexport, in hopes
it would be more straightforward and functional :)
Thanks,
Ben
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
