Hi Thomas,
As I indicated in my last e-mail, which you must not have received before sending this one, it is simplest to correct for the difference in (u,v) coordinates in the Radiance pattern specification. There is no need to either modify obj2mesh or the .OBJ exporter to obtain a correct mapping. Radiance coordinate mappings are programmable for a reason...
If you want to create a utility to automate the process, I suggest creating one that converts the texture input to Radiance picture format, simultaneously outputting an appropriate material/pattern definition, which must be served as an input to obj2mesh, anyway. If you're ambitious, you could even look into translating the material parameters to Radiance's physically-based model. Does this make sense?
-Greg
Hi Thomas,
As I indicated in my last e-mail, which you must not have received
before sending this one, it is simplest to correct for the difference
in (u,v) coordinates in the Radiance pattern specification. There
is no need to either modify obj2mesh or the .OBJ exporter to obtain
a correct mapping. Radiance coordinate mappings are programmable
for a reason...
I received you message 15 minutes to late. Anyway I changed it now
according to your example (that could be included in the man-page,
btw.).
If you want to create a utility to automate the process, I suggest
creating one that converts the texture input to Radiance picture
format, simultaneously outputting an appropriate material/pattern
definition, which must be served as an input to obj2mesh, anyway.
I have done that already. I can't count on the existence of the
texture image in the filesystem (could be stored in the Blender
scene file) so the image is created if necessary, converted to
HDR and saved as a resource for the Radiance scene.
Optionally I could apply 'normpat' as well but the default texture
(rgb = 0.9) does not need that. The image aspect is now part of
the texture definition as well.
If you're ambitious, you could even look into translating the
material parameters to Radiance's physically-based model. Does
this make sense?
We thought about that but the material definitions used in Blender
(and probably all other 3D modelers) are only useful to define
a nice looking material, not one that's physically correct. We
will use a 'library' instead and define the Radiance description
by assignment or name.
Same thing with luminaires BTW. The typical 3D object 'lamp' has
not enough information to define a real world luminaire. Our
library backend for luminaires may be the topic of another post
in a few days.
Thomas
ยทยทยท
On 20.02.2006, at 18:18, Gregory J. Ward wrote: